OpenTelemetry para AEM opentelemetry-apm

Adobe está reemplazando la integración de Application Performance Monitoring (APM) integrada en AEM as a Cloud Service por OpenTelemetry, un enfoque abierto y estándar en la industria para la observabilidad compatible con cada plataforma de monitoreo principal.

En la actualidad, AEM as a Cloud Service incluye una integración de APM integrada, administrada en su totalidad por Adobe. A medida que reemplace esa integración, necesitará traer su propio extremo de APM, ya sea una plataforma de proveedor que acepte datos de OpenTelemetry o un backend autoalojado (local) compatible con OpenTelemetry.

Ventajas de este cambio benefits

Información general overview

AEM as a Cloud Service puede emitir telemetría desde su aplicación utilizando OpenTelemetry, un enfoque abierto y estándar en la industria para la observabilidad, y reenviarla al proveedor de APM de su elección. Esto permite supervisar la aplicación de AEM junto con el resto de los sistemas, en las herramientas que ya utilizan los equipos.

Algunas razones comunes para utilizar esta integración son la investigación de solicitudes lentas o fallidas, el seguimiento del estado de JVM y el uso de recursos a lo largo del tiempo, la creación de paneles y alertas para los niveles de AEM y la correlación del comportamiento de AEM con el resto de los servicios durante un incidente, todo sin salir de las herramientas de monitorización que sus equipos ya utilizan.

La siguiente telemetría está en ámbito:

El reenvío de registros sigue siendo compatible a través de su mecanismo independiente existente y no se ve afectado por esta integración.

Para saber cómo funciona, incluyendo cómo fluye la telemetría de AEM a su plataforma APM, qué controla y cómo elegir una plataforma, consulte el tutorial Observabilidad a través de OpenTelemetry.

Versiones de OpenTelemetry compatibles supported-versions

El agente OpenTelemetry se ejecuta como parte del tiempo de ejecución de Cloud Service. Adobe lo proporciona y lo mantiene actualizado, por lo que no es necesario que lo instale, administre ni actualice usted mismo. La versión del parche específica puede cambiar a medida que Adobe actualiza el agente.

Variantes de OpenTelemetry admitidas supported-variants

Su aplicación de AEM puede instrumentarse con cualquiera de las siguientes variantes de agente OpenTelemetry (distribuciones), todas basadas en la versión anterior. Consulte la documentación de cada proyecto para obtener más información:

La variante ascendente predeterminada funciona con cualquier proveedor de APM. Las variantes Grafana y Splunk agregan instrumentación específica del proveedor y valores predeterminados para esas plataformas. Adobe instala la variante del agente seleccionada en el contenedor de AEM durante el despliegue. Durante la disponibilidad limitada, la variante ascendente se usa de manera predeterminada; para usar la variante Grafana o Splunk, pídelo cuando solicites acceso. El archivo config/otel.yaml configura hacia dónde va la telemetría; no tiene campo para seleccionar la variante del agente.

Proveedores de APM apm-vendors

Puede enviar la telemetría a cualquier proveedor de supervisión del rendimiento de la aplicación que acepte datos de OpenTelemetry a través de OTLP/HTTPS. Esto es independiente de la variante de OpenTelemetry que elija. Entre los proveedores compatibles con OTLP/HTTPS se incluyen:

Esta lista no es exhaustiva: se puede utilizar cualquier servidor que exponga un extremo OTLP/HTTPS.

Entornos compatibles supported-environments

Puede habilitar esta integración en los entornos de producción, fase y desarrollo de Cloud Manager. Cada entorno se habilita individualmente; consulte Paso 1. Los entornos de desarrollo rápido (RDE) no son compatibles.

Integraciones de APM existentes existing-apm

OpenTelemetry no se puede ejecutar junto con otro agente de APM en el mismo entorno:

Conectividad de red network-connectivity

Se debe poder acceder al punto de conexión de su proveedor de APM desde su entorno de AEM as a Cloud Service a través de HTTPS.

Si el extremo de APM es privado o necesita tráfico saliente para salir de una dirección IP estable y conocida, esta integración admite Redes avanzadas con salida dedicada. Consulte Redes avanzadas para saber cómo habilitarlas.

Qué datos se envían what-data-is-sent

Solo los seguimientos, las métricas y los registros (si están habilitados) generados por su aplicación de AEM se enviarán a su proveedor de APM. Los siguientes ejemplos ilustran el tipo de datos que puede esperar.

Seguimientos — abarca las solicitudes que administra su aplicación, entre ellas:

La actividad del planificador interno de gran volumen y de la sonda de estado (por ejemplo, los trabajos de Quartz) se filtra para que los seguimientos permanezcan centrados en las solicitudes de las aplicaciones.

Métricas — Métricas del tiempo de ejecución de JVM y del servidor HTTP, usando nombres de métricas estándar de OpenTelemetry, y métricas de AEM bajo el prefijo aem. (que se está desplegando; aparecen automáticamente, sin cambio de configuración), incluyendo:

Registros: las entradas de registro de su aplicación de AEM en el nivel WARN o superior se envían mediante la señal de registro de OpenTelemetry cuando está habilitada. Se está desarrollando la capacidad de ajustar este nivel de registro. Las entradas de registro llevan los mismos atributos de recurso que los seguimientos y las métricas (service.name, deployment.environment), así como los identificadores de seguimiento y de intervalo de la solicitud que los produjo, de modo que se puedan correlacionar con los seguimientos.

Los registros enviados de esta manera son independientes de Reenvío de registros; consulte Información general para ver por qué habilitar ambos para el mismo destino provoca duplicados.

Cómo se identifica la telemetría: cada seguimiento y métrica lleva atributos de recursos que identifican su origen, incluidos:

La información sobre el tiempo de ejecución de Cloud Service y la plataforma que aloja la aplicación (como nombres de host internos, direcciones, identificadores de contenedor y detalles del sistema operativo o del proceso) se elimina antes de que los datos abandonen el entorno.

Configuración de la integración set-up

Para obtener un tutorial guiado que utiliza el proyecto de ejemplo WKND, desde el almacenamiento de sus credenciales en Cloud Manager hasta la verificación de la telemetría en su plataforma de observabilidad, consulte el tutorial Configuración de OpenTelemetry para obtener información sobre las aplicaciones de AEM.

Paso 1: Solicitar acceso request-access

Envíe un correo electrónico a aemcs-apm-beta@adobe.com con su ID de programa de Cloud Manager y los ID de entorno que desea habilitar. Si desea utilizar la variante de agente Grafana o Splunk en lugar de la predeterminada, dígalo en su correo electrónico (consulte Variantes de OpenTelemetry compatibles).

Adobe habilita OpenTelemetry para esos entornos poco después de responder a su solicitud. Si un entorno utiliza actualmente la integración de APM integrada de Adobe, esa integración deja de enviar datos una vez que OpenTelemetry está habilitado; consulte Integraciones de APM existentes.

Paso 2: Añadir el archivo de configuración add-configuration

Agregue un archivo de config/otel.yaml a su repositorio de canalización de configuración de Cloud Manager. Como mínimo, especifique:

Consulte Configuración de ejemplo a continuación para ver el formato de archivo exacto, incluidos ejemplos de New Relic, Dynatrace, Grafana Cloud, Splunk, Datadog, Dash0 y extremos genéricos o autoalojados.

Paso 3: Configurar las credenciales de autenticación configure-credential

Proporcione la credencial que su proveedor de APM requiere declarando una variable de entorno secreta denominada OTEL_CUSTOMER_AUTH en Cloud Manager. Establezca Servicio aplicado en Todos para que las credenciales estén disponibles para los niveles de creación, publicación y vista previa.

Para agregar o actualizar variables de entorno, debe ser miembro de la función Administrador de implementación. Para ver el procedimiento completo, consulte Variables de entorno en Cloud Manager.

Establezca el valor según el método de autenticación del proveedor:

Configuración específica del proveedor provider-specific

La siguiente tabla resume el punto de conexión y la autenticación de algunos proveedores comunes. Confirme siempre los valores actuales en la documentación propia del proveedor. Para los proveedores que utilizan un encabezado personalizado (por ejemplo, New Relic y Datadog), establezca OTEL_CUSTOMER_AUTH solo en el valor de clave sin procesar y authHeaderName en el archivo de configuración con el nombre de encabezado correcto (consulte Ejemplo de configuración).

Ejemplo de configuración example-configuration

Agregue un archivo como uno de los siguientes ejemplos a config/otel.yaml en su repositorio de canalización de configuración, basado en su proveedor de configuración específica del proveedor.

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

Guión0:

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

Nube de Grafana:

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 (a través de una distribución Splunk del recolector de OpenTelemetry que se ejecuta como puerta de enlace):

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

Extremo genérico o autoalojado (por ejemplo, un recolector OpenTelemetry local):

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

Redes avanzadas (salida dedicada): para un extremo privado o uno que requiera que el tráfico salga de una dirección IP estable conocida (consulte Conectividad de red):

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

Paso 4: Implementación deploy

Una vez que Adobe haya confirmado que OpenTelemetry está habilitado para su entorno (consulte Paso 1), ejecute la canalización de configuración para implementar config/otel.yaml. La canalización valida la configuración y comprueba el punto de conexión y las credenciales antes de aplicar la configuración, por lo que la mayoría de los errores se notifican directamente en el registro de canalización.

Una vez finalizada la canalización, los seguimientos, las métricas y los registros (si están activados) de la aplicación de AEM empiezan a aparecer en el proveedor de APM. Use Paso 5 para confirmar.

Paso 5: Verificar la integración verify

Dado que la telemetría se envía a su propio proveedor de APM, usted confirma la integración desde las herramientas de su proveedor; Adobe no le devuelve estos datos.

Una vez finalizada la canalización, espere unos minutos para que lleguen los datos y, a continuación, compruebe si su proveedor de APM cumple los siguientes requisitos:

Si aparecen estos datos, la integración funciona.

Resolución de problemas troubleshooting

Si la telemetría no aparece en su proveedor de APM, compruebe lo siguiente:

Si la telemetría sigue sin aparecer después de estas comprobaciones, póngase en contacto con aemcs-apm-beta@adobe.com con los detalles de su programa y entorno.

Preguntas frecuentes faq

¿Por qué ocurre este cambio?

Los clientes de AEM as a Cloud Service han solicitado métricas y datos operativos adicionales, así como seguimientos, expansiones y registros en contexto. OpenTelemetry es un estándar de la industria que soporta todas estas capacidades, y las produce en un formato ampliamente soportado (OTLP).

¿Necesito solicitar acceso?

Sí. Durante la disponibilidad limitada, envíe un correo electrónico a aemcs-apm-beta@adobe.com con sus ID de programa y entorno. Adobe habilita OpenTelemetry para esos entornos poco después de responder a su solicitud. Esto aún no está disponible para entornos con ámbito HIPAA.

¿Qué le sucede a New Relic si habilito OpenTelemetry?

Una vez que Adobe habilita OpenTelemetry para un entorno a petición suya, los datos ya no se envían a New Relic desde ese entorno. Los dos no se pueden ejecutar al mismo tiempo.

Si migre a OpenTelemetry desde New Relic, ¿puedo retroceder?

Sí. Envíe un correo electrónico a aemcs-apm-beta@adobe.com y Adobe deshabilitará OpenTelemetry para sus entornos. A continuación, establezca enabled: false en su archivo config/otel.yaml (o elimine el archivo), ejecute la canalización de configuración y ejecute una canalización de pila completa hasta su finalización para restaurar New Relic. Esto es posible hasta finales de noviembre de 2026.

¿Puedo usar OpenTelemetry si mi entorno ejecuta Dynatrace OneAgent?

No en el mismo entorno: Dynatrace OneAgent tiene prioridad. Puede quitar OneAgent y utilizar OpenTelemetry en su lugar, incluso con Dynatrace como proveedor de APM. Ver integraciones de APM existentes.

¿Qué sucede después de noviembre de 2026?

Adobe pasará de su solución de APM integrada a OpenTelemetry como solución de observabilidad permanente.

Artículos relacionados related-articles