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.

Related Content