Dynatrace vs. OpenTelemetry (CloudWatch Application Signals)

[K-A]

■ Background
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.

Note
When Application Signals is enabled, it appears that an OpenTelemetry init container is automatically injected into the pod.

■ Question
We are currently using the Dynatrace Operator to monitor our Kubernetes cluster.
If we enable CloudWatch Application Signals, is there a possibility that the Dynatrace Operator will conflict with OpenTelemetry?
Also, is there a possibility of conflict with CloudWatch Application Signals?

For example, I am concerned about the following potential impacts:

• Impact on metric and trace collection by Dynatrace
• Impact on the functionality or behavior of the Dynatrace Operator
• Issues such as data loss, incomplete data collection, or interruptions in monitoring capabilities

[sujit_k_singh · Accepted solution]

Hi @K-A 

Yes, running both simultaneously will cause conflicts due to dual auto-instrumentation at the application runtime level.

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.

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.

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
instrumentation.opentelemetry.io/inject-java: "false"

Thanks,

Sujit