OpenTelemetry for AEM 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.

To learn how it works, including how telemetry flows from AEM to your APM platform, what you control, and how to choose a platform, see the tutorial Observability via OpenTelemetry.

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. 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. Adobe installs the selected agent variant in the AEM container at deployment. During Limited Availability, the upstream variant is used by default; to use the Grafana or Splunk variant, ask for it when you request access. The config/otel.yaml file configures where telemetry goes; it has no field to select the agent variant.

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.

Existing APM integrations existing-apm

OpenTelemetry cannot run alongside another APM agent on the same environment:

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.

Metrics — JVM runtime and HTTP server metrics, using standard OpenTelemetry metric names, and AEM metrics under the aem. prefix (being rolled out; they appear automatically, with no configuration change), including:

Logs — your AEM application’s log entries at WARN level and above, sent using OpenTelemetry’s logs signal, when enabled. The ability to adjust this log level is in development. Log entries carry the same resource attributes as traces and metrics (service.name, deployment.environment), and the trace and span identifiers of the request that produced them, so they can be correlated with traces.

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

For a guided walkthrough that uses the WKND sample project, from storing your credential in Cloud Manager to verifying telemetry in your observability platform, see the tutorial Configure OpenTelemetry for insights into AEM applications.

Step 1: Request access request-access

Email aemcs-apm-beta@adobe.com with your Cloud Manager program ID and the environment IDs you want to enable. If you want to use the Grafana or Splunk agent variant rather than the default, say so in your email (see Supported OpenTelemetry variants).

Adobe enables OpenTelemetry for those environments shortly after replying to your request. If an environment currently uses Adobe’s built-in APM integration, that integration stops sending data once OpenTelemetry is enabled — see Existing APM integrations.

Step 2: Add your configuration file add-configuration

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, Grafana Cloud, Splunk, Datadog, Dash0, and generic or self-hosted endpoints.

Step 3: 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: "1"
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: "1"
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: "1"
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: "1"
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

Grafana Cloud:

kind: "Otel"
version: "1"
metadata:
  envTypes:
    - "stage"
    - "prod"
data:
  enabled: true
  type: "grafana"
  endpoint: "https://otlp-gateway-<zone>.grafana.net/otlp"   # for example, https://otlp-gateway-prod-us-east-0.grafana.net/otlp
  authHeaderValue: "${{secrets.OTEL_CUSTOMER_AUTH}}"   # the secret's value must be "Basic <base64(instanceID:token)>"
  metrics: true
  logs: true

Splunk (through a Splunk Distribution of the OpenTelemetry Collector running as a gateway):

kind: "Otel"
version: "1"
metadata:
  envTypes:
    - "stage"
    - "prod"
data:
  enabled: true
  type: "splunk"
  endpoint: "https://<your-splunk-otel-collector>:4318"
  authHeaderValue: "${{secrets.OTEL_CUSTOMER_AUTH}}"   # the credential your gateway accepts, for example "Bearer <token>"
  metrics: true
  logs: true

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

kind: "Otel"
version: "1"
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: "1"
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 4: Deploy deploy

Once Adobe has confirmed that OpenTelemetry is enabled for your environment (see Step 1), run your Config Pipeline to deploy config/otel.yaml. The pipeline validates your configuration and checks your endpoint and credential before applying the configuration, so most mistakes are reported directly in the pipeline log.

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

Step 5: 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 the pipeline 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).

Do I need to request access?

Yes. During Limited Availability, email aemcs-apm-beta@adobe.com with your program and environment IDs. Adobe enables OpenTelemetry for those environments shortly after replying to your request. This is not yet available to HIPAA-scoped environments.

What happens to New Relic if I enable OpenTelemetry?

Once Adobe enables OpenTelemetry for an environment at your request, data is no longer sent to New Relic from that environment. The two cannot run at the same time.

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

Yes. Email aemcs-apm-beta@adobe.com and Adobe disables OpenTelemetry for your environments. Then set enabled: false in your config/otel.yaml file (or remove the file), run your Config Pipeline, and run a Full Stack pipeline to completion to restore New Relic. This is possible until the end of November 2026.

Can I use OpenTelemetry if my environment runs Dynatrace OneAgent?

Not on the same environment — Dynatrace OneAgent takes precedence. You can remove OneAgent and use OpenTelemetry instead, including with Dynatrace as your APM provider. See Existing APM integrations.

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