OpenTelemetry compatibility considerations
To onboard your applications with CloudWatch Application Signals, we recommend that you completely remove any existing application performance monitoring solution from your application beforehand. This includes removing any instrumentation code and configurations.
Even though Application Signals uses OpenTelemetry instrumentation, it is not guaranteed to be compatible with your existing OpenTelemetry instrumentation or configuration. In a best-case scenario, you might be able to keep some of your OpenTelemetry functionality, such as custom metrics. However, be sure to read the following sections for details.
Considerations if you already use OpenTelemetry
If you are already using OpenTelemetry with your application, the rest of this section contains important information to achieve compatibility with Application Signals.
Before you enable your application for Application Signals, you must remove the injection of any other auto-instrumentation agents based on OpenTelemetry from your application. This helps avoid configuration conflicts. You can continue to use manual instrumentation using compatible OpenTelemetry APIs along with Application Signals.
If you are using manual instrumentation to generate custom spans or metrics from your application, then depending on the complexity of the instrumentation, enabling Application Signals might cause them to stop generating data or have other undesirable behavior. You might be able to use some of the available configurations in OpenTelemetry (except for the ones mentioned in the table later in this section) to retain the desired behavior of your existing metrics or spans. For more information about these configurations, see SDK Configuration
in the OpenTelemetry documentation. For example, by using the
OTEL_EXPORTER_OTLP_METRICS_ENDPOINT
configuration and a self-managed OpenTelemetry Collector instance, you might be able to continue sending your custom metrics to your desired destination.Some environment variables or system properties must not be used with Application Signals, while you can use others as long as you follow the guidance in the table. See the following table for details.
Environment variable | Recommendation with Application Signals |
---|---|
General environment variables |
|
|
Must not be set to |
|
Must be set to |
|
Set to |
|
Must not be used. |
|
Must not be used. |
|
If set, must be set high enough to include approximately 10 more span attributes that are added by CloudWatch Application Signals. |
|
Must be set to |
|
If set, must include |
|
If set, must be To use local sampling, set this to |
|
If you are using the default of X-Ray centralized trace sample, this variable must not be used. If you are using local sampling instead, set the sampling rate in this variable. For example,
|
Java-specific environment variables |
|
|
If set, must include Amazon resource detectors. |
Python-specific environment variables |
|
|
If used, must be set to |
|
If used, must be set to |