OpenTelemetry (Beta) opentelemetry-apm

Adobe is replacing the Application Performance Monitoring (APM) integration built into AEM as a Cloud Service with OpenTelemetry, an open, industry-standard approach to observability supported by every major monitoring platform.

Today, AEM as a Cloud Service includes a built-in APM integration, managed entirely by Adobe. As that integration is replaced, you will need to bring your own APM endpoint — either a vendor platform that accepts OpenTelemetry data, or a self-hosted (on-premises) OpenTelemetry-compatible backend.

Benefits of this change benefits

Overview overview

AEM as a Cloud Service can emit telemetry from your application using OpenTelemetry, an open, industry-standard approach to observability, and forward it to the APM provider of your choice. This lets you monitor your AEM application alongside the rest of your systems, in the tools your teams already use.

Common reasons to use this integration include investigating slow or failing requests, tracking JVM health and resource usage over time, building dashboards and alerts for your AEM tiers, and correlating AEM behavior with the rest of your services during an incident — all without leaving the monitoring tools your teams already use.

The following telemetry is in scope:

Log Forwarding continues to be supported through its existing, separate mechanism, and is unaffected by this integration.

Supported OpenTelemetry versions supported-versions

The OpenTelemetry agent runs as part of the Cloud Service runtime. Adobe provides it and keeps it up to date, so you do not need to install, manage, or upgrade it yourself. The specific patch version may change as Adobe updates the agent.

Supported OpenTelemetry variants supported-variants

Your AEM application can be instrumented with any of the following OpenTelemetry agent variants (distributions), all based on the version above. Choose the variant that suits your tooling; see each project’s documentation for details:

The default upstream variant works with any APM vendor. The Grafana and Splunk variants add vendor-specific instrumentation and defaults for those platforms.

APM vendors apm-vendors

You can send your telemetry to any Application Performance Monitoring vendor that accepts OpenTelemetry data over OTLP/HTTPS. This is independent of the OpenTelemetry variant you choose. Vendors with OTLP/HTTPS support include:

This list is not exhaustive — any backend that exposes an OTLP/HTTPS endpoint can be used.

Supported environments supported-environments

You can enable this integration on your Cloud Manager production, stage, and development environments. Each environment is enabled individually — see Step 1. Rapid Development Environments (RDE) are not supported.

Network connectivity network-connectivity

Your APM provider’s endpoint must be reachable from your AEM as a Cloud Service environment over HTTPS.

If your APM endpoint is private, or you need outbound traffic to leave from a stable, known IP address, this integration supports Advanced Networking with dedicated egress. See Advanced Networking for how to enable it.

What data is sent what-data-is-sent

Only the traces, metrics, and (if enabled) logs generated by your AEM application are sent to your APM provider. The following examples illustrate the kind of data you can expect.

Traces — spans for the requests your application handles, including:

High-volume internal scheduler and health-probe activity (for example, Quartz jobs) is filtered out so that traces stay focused on application requests. Fine-grained AEM framework-internal spans — such as Sling resource resolution, OSGi services, or JCR access — are not emitted in this release.

Metrics — JVM runtime and HTTP server metrics, using standard OpenTelemetry metric names, including:

Logs — your AEM application’s log entries, sent using OpenTelemetry’s logs signal, when enabled. Log entries carry the same resource attributes as traces and metrics (service.name, deployment.environment), so they can be correlated with them.

Logs sent this way are independent of Log Forwarding — see Overview for why enabling both to the same destination causes duplicates.

How telemetry is identified — each trace and metric carries resource attributes that identify its source, including:

Information about the Cloud Service runtime and the platform that hosts your application — such as internal hostnames, addresses, container identifiers, and operating-system or process details — is removed before any data leaves your environment.

Set up the integration set-up

Step 1: Enable the integration request-access

Add a config/otel.yaml file to your Cloud Manager Config Pipeline repository. At minimum, specify:

See Example configuration below for the exact file format, including examples for New Relic, Dynatrace, Datadog, Dash0, and generic or self-hosted endpoints.

Step 2: Configure your authentication credential configure-credential

Provide the credential that your APM provider requires by declaring a secret environment variable named OTEL_CUSTOMER_AUTH in Cloud Manager. Set Service Applied to All so the credential is available to the author, publish, and preview tiers.

To add or update environment variables, you must be a member of the Deployment Manager role. For the full procedure, see Environment Variables in Cloud Manager.

Set the value according to your provider’s authentication method:

Provider-specific settings provider-specific

The following table summarizes the endpoint and authentication for some common providers. Always confirm the current values in your provider’s own documentation. For providers that use a custom header (for example, New Relic and Datadog), set OTEL_CUSTOMER_AUTH to the raw key value only, and set authHeaderName in your configuration file to the correct header name (see Example configuration).

Example configuration example-configuration

Add a file like one of the following examples to config/otel.yaml in your Config Pipeline repository, based on your provider from Provider-specific settings.

New Relic:

kind: "Otel"
version: "v1"
metadata:
  envTypes:
    - "stage"
    - "prod"
data:
  enabled: true
  type: "newrelic"
  endpoint: "https://otlp.nr-data.net"   # https://otlp.eu01.nr-data.net for the EU region
  authHeaderValue: "${{secrets.OTEL_CUSTOMER_AUTH}}"
  metrics: true   # optional
  logs: true      # optional — see Overview for the Log Forwarding duplicate-message warning

Dynatrace:

kind: "Otel"
version: "v1"
metadata:
  envTypes:
    - "stage"
    - "prod"
data:
  enabled: true
  type: "dynatrace"
  endpoint: "https://{your-environment-id}.live.dynatrace.com/api/v2/otlp"
  authHeaderValue: "${{secrets.OTEL_CUSTOMER_AUTH}}"   # the secret's value must be "Api-Token <token>"
  metrics: true
  logs: true

Datadog:

kind: "Otel"
version: "v1"
metadata:
  envTypes:
    - "stage"
    - "prod"
data:
  enabled: true
  type: "generic"
  endpoint: "https://otlp.<your-datadog-site>"   # for example, https://otlp.datadoghq.com
  authHeaderName: "dd-api-key"
  authHeaderValue: "${{secrets.OTEL_CUSTOMER_AUTH}}"   # the secret's value is the raw API key, no prefix
  metrics: true
  logs: true

Dash0:

kind: "Otel"
version: "v1"
metadata:
  envTypes:
    - "stage"
    - "prod"
data:
  enabled: true
  type: "generic"
  endpoint: "https://ingress.<region>.aws.dash0.com:4318"
  authHeaderValue: "${{secrets.OTEL_CUSTOMER_AUTH}}"   # the secret's value must be "Bearer <token>"
  metrics: true
  logs: true

Generic or self-hosted endpoint (for example, an on-premises OpenTelemetry collector):

kind: "Otel"
version: "v1"
metadata:
  envTypes:
    - "stage"
    - "prod"
data:
  enabled: true
  type: "generic"
  endpoint: "https://<your-otlp-endpoint>"
  authHeaderValue: "${{secrets.OTEL_CUSTOMER_AUTH}}"   # for example, "Basic <base64(user:pass)>"
  metrics: true
  logs: true

Advanced Networking (dedicated egress) — for a private endpoint, or one that requires traffic to leave from a known, stable IP address (see Network connectivity):

kind: "Otel"
version: "v1"
metadata:
  envTypes:
    - "stage"
    - "prod"
data:
  enabled: true
  type: "generic"
  endpoint: "https://<your-private-otlp-endpoint>"
  authHeaderValue: "${{secrets.OTEL_CUSTOMER_AUTH}}"
  metrics: true
  logs: true
  advancedNetworking: true   # routes this endpoint's egress through Advanced Networking instead of direct internet egress

Step 3: Deploy deploy

The integration takes effect on your environment’s next deployment — that is, the next time a deployment pipeline runs for the environment in Cloud Manager (for example, a full-stack deployment). If your environment has not been deployed since you added your config/otel.yaml file and set your credential, run a deployment to activate it.

After deployment, traces, metrics, and (if enabled) logs from your AEM application begin to appear in your APM provider. Use Step 4 to confirm.

Step 4: Verify the integration verify

Because telemetry is sent to your own APM provider, you confirm the integration from your provider’s tools; Adobe does not surface this data back to you.

After a deployment completes, allow a few minutes for data to arrive, then check your APM provider for the following:

If this data appears, the integration is working.

Troubleshooting troubleshooting

If telemetry does not appear in your APM provider, check the following:

If telemetry still does not appear after these checks, contact aemcs-apm-beta@adobe.com with your program and environment details.

FAQ faq

Why is this change happening?

AEM as a Cloud Service customers have asked for additional metrics and operational data, as well as traces, spans, and logs in context. OpenTelemetry is an industry standard that supports all of these capabilities, and outputs them in a widely supported format (OTLP).

What happens to New Relic if I enable OpenTelemetry?

When you run the Configuration Pipeline, data to New Relic will no longer be transmitted from AEM as a Cloud Service.

If I migrate to OpenTelemetry from New Relic, can I move back?

Yes. Disable OpenTelemetry via the Configuration Pipeline, then run a Full Stack pipeline to completion. This is possible until the end of November 2026.

What happens after November 2026?

Adobe will move from its built-in APM solution to OpenTelemetry as its permanent observability solution.

Related articles related-articles