<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>article Distributed trace breaks after IBM MQ/JMS span when mixing OneAgent (full-stack) and OpenTelemetry in Troubleshooting</title>
    <link>https://community.dynatrace.com/t5/Troubleshooting/Distributed-trace-breaks-after-IBM-MQ-JMS-span-when-mixing/ta-p/303022</link>
    <description>&lt;DIV class="lia-message-template-content-zone"&gt;
&lt;H2&gt;Summary&lt;/H2&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;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.&lt;BR /&gt;This article explains why this happens, what workarounds exist, and what the fully supported resolution is.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;H2&gt;Problem&lt;/H2&gt;
&lt;P&gt;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. &lt;CODE&gt;&amp;lt;QUEUE_NAME&amp;gt; (IBM MQ)&lt;/CODE&gt;). 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.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;A distributed trace for a flow such as:&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;
&lt;BLOCKQUOTE&gt;&lt;STRONG&gt;API Gateway (OneAgent) → Service A (OneAgent) → IBM MQ → Service B (OpenTelemetry)&lt;/STRONG&gt;&lt;/BLOCKQUOTE&gt;
&lt;P&gt;shows only the first part of the call chain. The trace appears to stop at the IBM MQ span (for example, &lt;CODE&gt;SERVICE.QUEUE.NAME RES (IBM MQ)&lt;/CODE&gt;). Downstream activity from Service B onward is visible only as a separate, disconnected trace with a different trace ID.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;H2&gt;Troubleshooting steps&lt;/H2&gt;
&lt;P&gt;&lt;STRONG&gt;Root cause&lt;/STRONG&gt;&lt;BR aria-hidden="true" /&gt;This is expected behavior, not a bug. The OneAgent JMS/MQ sensor uses &lt;A href="https://docs.dynatrace.com/docs/observe/application-observability/distributed-tracing/tracking-transactions#propagation-mechanisms" target="_self"&gt;Dynatrace-proprietary messaging trace headers&lt;/A&gt; (the &lt;CODE&gt;dtdTraceTag&lt;/CODE&gt; / &lt;CODE&gt;dtdTraceTagInfo&lt;/CODE&gt; format) to propagate trace context across message queues.&lt;BR /&gt;OpenTelemetry does not understand Dynatrace-specific headers. It expects W3C Trace Context headers (&lt;CODE&gt;traceparent&lt;/CODE&gt;, &lt;CODE&gt;tracestate&lt;/CODE&gt;). Because the consumer (OTel side) cannot read the &lt;CODE&gt;dtdTraceTag&lt;/CODE&gt; that the producer (OneAgent) set on the message, it cannot attach its spans to the original trace — resulting in a broken trace.&lt;BR /&gt;&lt;BR /&gt;This limitation is specific to &lt;STRONG&gt;messaging protocols (JMS, IBM MQ)&lt;/STRONG&gt;. It does &lt;STRONG&gt;not&lt;/STRONG&gt; apply to HTTP, gRPC, Kafka, or AWS SQS, where OneAgent and OpenTelemetry can both use/understand W3C trace context headers.&lt;BR /&gt;&lt;BR /&gt;Note: enabling &lt;STRONG&gt;Server-side Monitoring → Deep Monitoring → Distributed Tracing → "Send W3C trace context"&lt;/STRONG&gt; does &lt;I&gt;not&lt;/I&gt; 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.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;H2&gt;Resolution&lt;/H2&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;OL&gt;
&lt;LI&gt;&lt;STRONG&gt;Instrument the consumer side with OneAgent as well (recommended).&lt;/STRONG&gt; 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).&lt;/LI&gt;
&lt;LI&gt;&lt;STRONG&gt;Disable the OneAgent messaging sensors (JMS/MQ) and implement OpenTelemetry spans across the messaging boundary instead.&lt;/STRONG&gt; This requires application code changes: the producer and consumer both need the OTel SDK to create spans and propagate context (e.g. via &lt;CODE&gt;traceparent&lt;/CODE&gt;/&lt;CODE&gt;tracestate&lt;/CODE&gt;) in message headers.&lt;/LI&gt;
&lt;/OL&gt;
&lt;P&gt;&lt;EM&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;/EM&gt;&lt;/P&gt;
&lt;H2&gt;What's next&lt;/H2&gt;
&lt;P&gt;If this article did not help, please open a support ticket, mention that this article was used and provide the following in the ticket:&lt;/P&gt;
&lt;P&gt;1. Broken Distributed traces links for both upstream and downstream call.&lt;/P&gt;
&lt;P&gt;2. Support archive&lt;/P&gt;
&lt;H3&gt;&amp;nbsp;&lt;/H3&gt;
&lt;/DIV&gt;</description>
    <pubDate>Tue, 18 Aug 2026 06:20:24 GMT</pubDate>
    <dc:creator>shahna_khalid</dc:creator>
    <dc:date>2026-08-18T06:20:24Z</dc:date>
    <item>
      <title>Distributed trace breaks after IBM MQ/JMS span when mixing OneAgent (full-stack) and OpenTelemetry</title>
      <link>https://community.dynatrace.com/t5/Troubleshooting/Distributed-trace-breaks-after-IBM-MQ-JMS-span-when-mixing/ta-p/303022</link>
      <description>&lt;P&gt;&lt;LI-TOC indent="15" liststyle="disc" maxheadinglevel="2"&gt;&lt;/LI-TOC&gt;&lt;/P&gt;
&lt;DIV class="lia-message-template-content-zone"&gt;
&lt;P&gt;*&lt;EM&gt;Use a table of contents for longer articles.&amp;nbsp;&lt;/EM&gt;&lt;/P&gt;
&lt;H2&gt;Summary&lt;/H2&gt;
&lt;P&gt;&lt;EM&gt;*This is a mandatory section.&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;Short description of which part of the Dynatrace platform the article refers to and what kind of problem it will help resolve/ task it will describe.&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;H2&gt;Problem&lt;/H2&gt;
&lt;P&gt;&lt;EM&gt;*This is a mandatory section.&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;Provide a precise description of the problem/ task to be described. Use anonymized screenshots, and include text for&amp;nbsp;important messages, errors, or information that will help the customer find this article when searching.&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;H2&gt;Troubleshooting steps&lt;/H2&gt;
&lt;P&gt;&lt;EM&gt;*This section can be omitted as necessary.&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;Explain what troubleshooting steps should be taken to ensure the problem matches this article.&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;H2&gt;Resolution&lt;/H2&gt;
&lt;P&gt;&lt;EM&gt;*This section can be omitted for articles that guide customers on ticket creation.&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;Explain the solution or all possible solutions resulting from the troubleshooting steps.&lt;BR /&gt;&lt;BR /&gt;&lt;/EM&gt;&lt;/P&gt;
&lt;H2&gt;What's next&lt;/H2&gt;
&lt;P&gt;&lt;EM&gt;*This is a mandatory section. Customers need a way to respond or follow up if they have questions.&amp;nbsp;&lt;/EM&gt;&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;Explain what to do if the article did not help.&amp;nbsp;&lt;/EM&gt;&lt;EM&gt;Note that there are multiple options available, including:&lt;/EM&gt;&lt;/P&gt;
&lt;OL&gt;
&lt;LI&gt;&lt;EM&gt;&lt;STRONG&gt;Opening a support ticket&lt;/STRONG&gt; - be as specific as possible about the information the customer should include in the ticket.&amp;nbsp;&lt;/EM&gt; If this article did not help, please open a support ticket, mention that this article was used and provide the following in the ticket:
&lt;UL&gt;
&lt;LI&gt;link to XYZ&lt;/LI&gt;
&lt;LI&gt;screenshot of XYZ&lt;/LI&gt;
&lt;LI&gt;information about XYZ&lt;/LI&gt;
&lt;/UL&gt;
&lt;/LI&gt;
&lt;LI&gt;&lt;EM&gt;&lt;STRONG&gt;Suggesting Product Idea&lt;/STRONG&gt; - encourage the customer to suggest/ vote for a Product Idea explaining their business use case.&lt;/EM&gt;&lt;/LI&gt;
&lt;LI&gt;&lt;EM&gt;&lt;STRONG&gt;Explain this will change in the future&lt;/STRONG&gt; - explain that this behaviour will change in a future release. (No product idea / support ticket needed)&lt;/EM&gt;&lt;/LI&gt;
&lt;LI&gt;&lt;EM&gt;&lt;STRONG&gt;Alternatives -&lt;/STRONG&gt;&amp;nbsp;any other actions or links to other articles that could move the customer forward.&lt;/EM&gt;&lt;/LI&gt;
&lt;/OL&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;EM&gt;*If it exists, link this article to the relevant troubleshooting map using the following guideline&lt;/EM&gt;&lt;/P&gt;
&lt;H3&gt;More articles can be found on the &lt;A href="https://community.dynatrace.com/t5/Troubleshooting/" target="_self"&gt;XXX Troubleshooting Map&lt;/A&gt;&lt;/H3&gt;
&lt;/DIV&gt;</description>
      <pubDate>Tue, 18 Aug 2026 06:20:24 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Troubleshooting/Distributed-trace-breaks-after-IBM-MQ-JMS-span-when-mixing/ta-p/303022</guid>
      <dc:creator>shahna_khalid</dc:creator>
      <dc:date>2026-08-18T06:20:24Z</dc:date>
    </item>
  </channel>
</rss>

