Summary
When Dynatrace OneAgent (full-stack) is used on the producer side of an IBM MQ / JMS messaging flow and OpenTelemetry (OTel) is used on the consumer side, distributed traces will appear broken — the trace does not continue past the IBM MQ span into the downstream service.
This article explains why this happens, what workarounds exist, and what the fully supported resolution is.
Problem
When a transaction flows through a IBM MQ via JMS between a service instrumented with Dynatrace OneAgent (full-stack) and a service instrumented with OpenTelemetry, the distributed trace stops at the messaging span (e.g. <QUEUE_NAME> (IBM MQ)). Downstream processing done by the OpenTelemetry-instrumented consumer does not appear as a continuation of the same trace — you end up with two (or more) disconnected traces instead of one end-to-end trace.
A distributed trace for a flow such as:
API Gateway (OneAgent) → Service A (OneAgent) → IBM MQ → Service B (OpenTelemetry)
shows only the first part of the call chain. The trace appears to stop at the IBM MQ span (for example, SERVICE.QUEUE.NAME RES (IBM MQ)). Downstream activity from Service B onward is visible only as a separate, disconnected trace with a different trace ID.
Troubleshooting steps
Root cause
This is expected behavior, not a bug. The OneAgent JMS/MQ sensor uses Dynatrace-proprietary messaging trace headers (the dtdTraceTag / dtdTraceTagInfo format) to propagate trace context across message queues.
OpenTelemetry does not understand Dynatrace-specific headers. It expects W3C Trace Context headers (traceparent, tracestate). Because the consumer (OTel side) cannot read the dtdTraceTag that the producer (OneAgent) set on the message, it cannot attach its spans to the original trace — resulting in a broken trace.
This limitation is specific to messaging protocols (JMS, IBM MQ). It does not apply to HTTP, gRPC, Kafka, or AWS SQS, where OneAgent and OpenTelemetry can both use/understand W3C trace context headers.
Note: enabling Server-side Monitoring → Deep Monitoring → Distributed Tracing → "Send W3C trace context" does not fix this for JMS/MQ — that setting only helps for HTTP, gRPC, SQS, and Kafka gaps. The OneAgent JMS/MQ sensor doesn't respect it.
Resolution
- Instrument the consumer side with OneAgent as well (recommended). When both sides use OneAgent, Dynatrace's native messaging propagation mechanism handles the JMS/MQ hop natively and the trace stitches automatically — testing confirmed OneAgent full-stack instrumentation on both producer and consumer fully connects spans across an IBM MQ hop (including with the MQI API).
- Disable the OneAgent messaging sensors (JMS/MQ) and implement OpenTelemetry spans across the messaging boundary instead. This requires application code changes: the producer and consumer both need the OTel SDK to create spans and propagate context (e.g. via
traceparent/tracestate) in message headers.
What's next
If this article did not help, please open a support ticket, mention that this article was used and provide the following in the ticket:
1. Broken Distributed traces links for both upstream and downstream call.
2. Support archive
