MQ

 View Only

 Distributed Tracing Using Opentelemetry

Aryan Singh's profile image
Aryan Singh posted 08/05/26 06:10 AM

Hi everyone,

I'm adding distributed tracing to a set of applications that use the IBM MQ classes for JMS, instrumented with the OpenTelemetry Java agent's built-in JMS auto-instrumentation. I'd appreciate the community's guidance on the cleanest, IBM-supported way to solve a correlation problem.

The Problem

The auto-generated JMS spans record the destination (queue) name but carry no queue manager identity. Since queue names aren't globally unique—the same queue name exists across multiple queue managers and environments—I can't reliably tell which queue manager a given put/get actually routed to. I want to enrich each messaging operation with a stable, globally unique queue manager identifier. The QMID (MQCA_Q_MGR_IDENTIFIER) looks ideal, and I'd prefer to extract this without modifying the application source.

What I've found and tried so far:

  • QMID is readable via a base-MQI MQINQ on MQCA_Q_MGR_IDENTIFIER (needs only +connect/+inq), but pure JMS doesn't appear to expose it. There is no JMS property and nothing in the message descriptor.

  • I can unwrap the JMS connection (com.ibm.mq.jms.MQConnection → internal provider connection → getQueueManagerName()) and then run a scoped MQINQ to fetch the QMID. However, reaching into internal classes feels fragile and version-coupled, and the scoped MQINQ opens a second authenticated connection.

Questions:

  1. Is there a supported way to read the QMID (or any globally unique QM identifier) directly from an IBM MQ JMS connection—perhaps via a JMS property, connection metadata, or a documented API—without requiring a separate MQINQ?

  2. Is there a supported accessor to the underlying MQI connection handle from a JMS connection? This would let me run MQINQ on the live, already-authenticated connection instead of opening a new one.

  3. For clients connecting via a CCDT, a queue manager group, or a blank QM name, what is the canonical, supported way to determine the actual queue manager the connection resolved to at runtime (name and/or QMID)?

  4. On the consuming side (JMS receive()), is there a supported way to identify which queue manager a received message originated from?

Environment:

  • IBM MQ classes for Java/JMS, client mode over a SVRCONN channel; applications talk to one or more queue managers.

  • OpenTelemetry Java agent auto-instrumentation for JMS.

  • Constraint: Prefer no application source changes (enrichment via an OTel agent extension or configuration is fine).

Thanks in advance—happy to share more detail on any of these.

MATTHEW LEMING's profile image
MATTHEW LEMING posted 08/26/26 12:50 PM

Hi Aryan,

Do the queue managers not have OTel enabled on them? If so the trace would have that information from the queue manager spans even if the JMS spans didn't. Would that not be enough?

Regards, Matt.

Francois Brandelik's profile image
Francois Brandelik IBM Champions posted 08/27/26 08:46 AM

If Matt's response is not satisfactory, you can use the same JMS session / context to issue a PCF message over JMS. The answer will then come as JMS response and need to be converted back into a PCF message where you can read the information you are looking for....

Hope this helps

Mark Taylor's profile image
Mark Taylor posted 09/02/26 07:46 AM

If you've got an MQ Connection object, then connection.toString()` might be helpful. It returns a JSON-formatted string that can be parsed:

{"ConnectionId":"414D5143514D31202020202020202020B5537C6A558D9E43","ObjectId":"com.ibm.msg.client.jakarta.wmq.internal.WMQConnection@3c407114","Channel":"SYSTEM.DEF.SVRCONN","Port":"1414","ConnectionMode":"WMQ_CM_CLIENT","Host":"localhost/127.0.0.1","ResolvedQueueManager":"QM1","QueueManager":"QM1"}

Related Content