<?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>topic Dynatrace vs. OpenTelemetry (CloudWatch Application Signals) in Container platforms</title>
    <link>https://community.dynatrace.com/t5/Container-platforms/Dynatrace-vs-OpenTelemetry-CloudWatch-Application-Signals/m-p/302789#M3594</link>
    <description>&lt;P&gt;&lt;STRONG&gt;■ Background&lt;/STRONG&gt;&lt;BR /&gt;According to AWS documentation, when you upgrade the Amazon CloudWatch Observability EKS add-on (and Helm charts) to major version 5.0.0, CloudWatch Application Signals is enabled by default.&lt;/P&gt;&lt;P&gt;Note&lt;BR /&gt;When Application Signals is enabled, it appears that an OpenTelemetry init container is automatically injected into the pod.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;■ Question&lt;/STRONG&gt;&lt;BR /&gt;We are currently using the Dynatrace Operator to monitor our Kubernetes cluster.&lt;BR /&gt;If we enable CloudWatch Application Signals, is there a possibility that the Dynatrace Operator will conflict with OpenTelemetry?&lt;BR /&gt;Also, is there a possibility of conflict with CloudWatch Application Signals?&lt;/P&gt;&lt;P&gt;For example, I am concerned about the following potential impacts:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Impact on metric and trace collection by Dynatrace&lt;/LI&gt;&lt;LI&gt;Impact on the functionality or behavior of the Dynatrace Operator&lt;/LI&gt;&lt;LI&gt;Issues such as data loss, incomplete data collection, or interruptions in monitoring capabilities&lt;/LI&gt;&lt;/UL&gt;</description>
    <pubDate>Tue, 04 Aug 2026 05:00:30 GMT</pubDate>
    <dc:creator>K-A</dc:creator>
    <dc:date>2026-08-04T05:00:30Z</dc:date>
    <item>
      <title>Dynatrace vs. OpenTelemetry (CloudWatch Application Signals)</title>
      <link>https://community.dynatrace.com/t5/Container-platforms/Dynatrace-vs-OpenTelemetry-CloudWatch-Application-Signals/m-p/302789#M3594</link>
      <description>&lt;P&gt;&lt;STRONG&gt;■ Background&lt;/STRONG&gt;&lt;BR /&gt;According to AWS documentation, when you upgrade the Amazon CloudWatch Observability EKS add-on (and Helm charts) to major version 5.0.0, CloudWatch Application Signals is enabled by default.&lt;/P&gt;&lt;P&gt;Note&lt;BR /&gt;When Application Signals is enabled, it appears that an OpenTelemetry init container is automatically injected into the pod.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;■ Question&lt;/STRONG&gt;&lt;BR /&gt;We are currently using the Dynatrace Operator to monitor our Kubernetes cluster.&lt;BR /&gt;If we enable CloudWatch Application Signals, is there a possibility that the Dynatrace Operator will conflict with OpenTelemetry?&lt;BR /&gt;Also, is there a possibility of conflict with CloudWatch Application Signals?&lt;/P&gt;&lt;P&gt;For example, I am concerned about the following potential impacts:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Impact on metric and trace collection by Dynatrace&lt;/LI&gt;&lt;LI&gt;Impact on the functionality or behavior of the Dynatrace Operator&lt;/LI&gt;&lt;LI&gt;Issues such as data loss, incomplete data collection, or interruptions in monitoring capabilities&lt;/LI&gt;&lt;/UL&gt;</description>
      <pubDate>Tue, 04 Aug 2026 05:00:30 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Container-platforms/Dynatrace-vs-OpenTelemetry-CloudWatch-Application-Signals/m-p/302789#M3594</guid>
      <dc:creator>K-A</dc:creator>
      <dc:date>2026-08-04T05:00:30Z</dc:date>
    </item>
    <item>
      <title>Re: Dynatrace vs. OpenTelemetry (CloudWatch Application Signals)</title>
      <link>https://community.dynatrace.com/t5/Container-platforms/Dynatrace-vs-OpenTelemetry-CloudWatch-Application-Signals/m-p/302792#M3595</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://community.dynatrace.com/t5/user/viewprofilepage/user-id/63154"&gt;@K-A&lt;/a&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Yes, running both simultaneously will cause conflicts due to dual auto-instrumentation at the application runtime level.&lt;/P&gt;&lt;P&gt;Since CloudWatch Application Signals is powered by ADOT under the hood, the same conflict rules apply. If you use ADOT auto-instrumentation agents alongside Dynatrace OneAgent on the same pod, they will fight for bytecode manipulation hooks.&lt;/P&gt;&lt;P&gt;Application Crashes (Primary Risk): Both Dynatrace OneAgent and the ADOT init container use runtime agents (e.g., Java -javaagent, .NET profilers) to alter bytecode. Running both on the same pod leads to class loader conflicts, startup failures, or pod crashes.&lt;/P&gt;&lt;P&gt;So you can do Dynatrace APM + Disable ADOT Auto-Injection - Keep Dynatrace handling application code-level tracing, but disable ADOT/App Signals auto-injection on those workloads via pod annotation&lt;BR /&gt;instrumentation.opentelemetry.io/inject-java: "false"&lt;/P&gt;&lt;P&gt;Thanks,&lt;/P&gt;&lt;P&gt;Sujit&lt;/P&gt;</description>
      <pubDate>Tue, 04 Aug 2026 06:20:43 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Container-platforms/Dynatrace-vs-OpenTelemetry-CloudWatch-Application-Signals/m-p/302792#M3595</guid>
      <dc:creator>sujit_k_singh</dc:creator>
      <dc:date>2026-08-04T06:20:43Z</dc:date>
    </item>
  </channel>
</rss>

