Observabilidad mediante OpenTelemetry

Descubra cómo AEM as a Cloud Service utiliza OpenTelemetry para enviar seguimientos, métricas y registros a la plataforma de monitorización del rendimiento de las aplicaciones (APM) que elija.

Adobe está reemplazando la integración de supervisión del rendimiento de las aplicaciones (APM) en AEM as a Cloud Service por OpenTelemetry, un estándar abierto para recopilar y exportar seguimientos, métricas y registros. Con OpenTelemetry, traes tu propio punto final de APM y monitoreas AEM junto con el resto de tus aplicaciones, usando las herramientas que tus equipos ya conocen. Para obtener más información, consulte la documentación de OpenTelemetry.

En este artículo se explica lo que proporciona la integración, cómo fluye la telemetría desde AEM a la plataforma de APM, qué controla y qué debe tener en cuenta antes de habilitarla. En el tutorial de configuración se explica cómo configurar OpenTelemetry para su entorno de AEM.

AVAILABILITY
Esta característica se encuentra en disponibilidad limitada. Para usarlo, solicite acceso enviando un correo electrónico a aemcs-apm-beta@adobe.com . Adobe habilita OpenTelemetry para sus entornos poco después de responder a su solicitud. Si su entorno utiliza actualmente la integración integrada de APM de Adobe, esa integración deja de enviar datos una vez que OpenTelemetry está habilitado, ya que las dos no se pueden ejecutar al mismo tiempo.
Tenga en cuenta que no está disponible para entornos con ámbito HIPAA, entornos de desarrollo rápido (RDE) y zonas protegidas.

Por qué OpenTelemetry

Con OpenTelemetry, puede:

  • Elija su plataforma: Envíe telemetría a cualquier servidor que acepte el protocolo OpenTelemetry a través de HTTPS (OTLP/HTTPS), incluido su proveedor actual si es compatible con OTLP.
  • Ver la imagen completa: obtenga seguimientos, métricas y registros a través de una integración, en lugar de mecanismos independientes.
  • Investigue más rápido: encuentre solicitudes lentas o con errores, realice un seguimiento del estado de JVM a lo largo del tiempo y correlacione el comportamiento de AEM con los demás servicios durante un incidente.
  • Manténgase en control: configure a qué destino enviar datos mediante la canalización de configuración de Cloud Manager y administre paneles, alertas y retención en su propia plataforma.

Adobe proporciona y actualiza el agente Java de OpenTelemetry que se ejecuta con AEM, por lo que no es necesario instalarlo ni actualizarlo. Tú decides dónde va la telemetría.

Funcionamiento

El diagrama siguiente muestra el flujo lógico de telemetría desde los servicios de AEM a su plataforma de observabilidad:

Flujo lógico de telemetría desde los servicios de AEM hasta la plataforma de observación del cliente

El agente Java OpenTelemetry recopila telemetría de aplicaciones de los servicios de AEM y la envía a un recopilador de OpenTelemetry que se ejecuta en el entorno de AEM. El recolector procesa la telemetría y la reenvía a través de OTLP/HTTPS a su plataforma de observabilidad configurada.

Solo se envía la telemetría generada por la aplicación de AEM. La información sobre el tiempo de ejecución y la plataforma subyacentes, como los nombres de host internos, las direcciones, los identificadores de contenedor y los detalles del sistema operativo o del proceso, se eliminan antes de que los datos abandonen el entorno.

Qué telemetría está disponible

Señal
Lo que obtienes
Cómo habilitarlo
Rastreos
Abarca las solicitudes que administra la aplicación: solicitudes HTTP entrantes, procesamiento de servlet y llamadas salientes.
Configure e implemente el archivo otel.yaml mediante la canalización de configuración de Cloud Manager. Vea tutorial de configuración
Métricas
Métricas de tiempo de ejecución de JVM (memoria, recolección de basura, subprocesos, utilización de CPU) y métricas de solicitud de servidor HTTP (tasa, latencia y tasa de error).
Configure e implemente el archivo otel.yaml con metrics: true mediante la canalización de configuración de Cloud Manager. Vea tutorial de configuración
Registros
Entradas de registro de aplicaciones de AEM (WARN y superiores), enviadas mediante la señal de registros de OpenTelemetry. Nota: No se envían los registros de Dispatcher y CDN.
Configure e implemente el archivo otel.yaml con logs: true mediante la canalización de configuración de Cloud Manager. Vea tutorial de configuración

Algunos detalles a tener en cuenta:

  • Para mantener los seguimientos centrados en las solicitudes de aplicaciones, se filtra la actividad interna de gran volumen, como los sondeos de estado y los trabajos del programador (Quartz).
  • En esta versión no se emiten espacios internos del marco de trabajo de AEM específicos, como la resolución de recursos de Sling, los servicios OSGi y el acceso JCR.
  • Las métricas utilizan nombres estándar de OpenTelemetry, por ejemplo jvm.memory.used, jvm.gc.duration, jvm.thread.count y http.server.request.duration.
WARNING
Si envía registros a través de OpenTelemetry y a través de Reenvío de registros al mismo destino, recibirá mensajes de registro duplicados. Habilite solo una ruta por destino o envíe cada ruta a un destino diferente.
El reenvío de registros es un mecanismo independiente y sigue funcionando como en la actualidad.

Identificación de los servicios de AEM

Cada entrada de seguimiento, métrica y registro lleva atributos de recursos que permiten que su plataforma distinga entornos y niveles:

  • service.name identifica el programa, el entorno, el nivel y el tipo de entorno, siguiendo este patrón:

    code language-text
    cm-p<program>-e<environment>-aem-<author|publish|preview>-<environment-type>
    

    Por ejemplo, cm-p12345-e67890-aem-publish-prod es el servicio de publicación del entorno 67890 en 12345 de programa, que se ejecuta en un entorno de producción.

  • deployment.environment identifica el tipo de entorno, como prod o stage.

Utilice estos atributos para filtrar y agrupar la telemetría, así como para correlacionar registros con seguimientos y métricas del mismo servicio.

Qué controla

La integración se configura implementando el archivo config/otel.yaml mediante la canalización de configuración de Cloud Manager.

El archivo de configuración de ejemplo es:

kind: "Otel"
version: "v1"
metadata:
  envTypes:
    - "dev"
    - "stage"
    - "prod"
data:
  enabled: true
  type: "generic"
  endpoint: "<YOUR_OTLP_HTTPS_ENDPOINT>"
  authHeaderName: "Authorization"
  authHeaderValue: "${{secrets.OTEL_CUSTOMER_AUTH}}"
  metrics: true
  logs: true
  advancedNetworking: false

La configuración determina lo siguiente:

  • Los tipos de entorno (prod, stage, dev) a los que se aplica
  • El tipo de destino (newrelic, dynatrace, generic, etc.) y punto final OTLP/HTTPS
  • La credencial de autenticación (authHeaderName y authHeaderValue), a la que se hace referencia como una variable de entorno secret de Cloud Manager denominada OTEL_CUSTOMER_AUTH
  • Si las métricas (metrics: true) y los registros (logs: true) se exportan además de los seguimientos
  • Si se usa la red avanzada (advancedNetworking: true) para el destino

La credencial de autenticación (authHeaderValue) debe almacenarse como una variable de entorno de Cloud Manager secret denominada OTEL_CUSTOMER_AUTH y referenciada desde el archivo de configuración. Nunca almacene credenciales como texto sin formato en el repositorio.

Si el extremo OTLP/HTTPS es privado o requiere tráfico saliente desde una dirección IP estable conocida, habilite Redes avanzadas con salida dedicada. La configuración advancedNetworking no tiene efecto a menos que Cloud Manager ya haya aprovisionado la función de red avanzada para el entorno. Un extremo SaaS público utiliza la ruta de red saliente estándar.

Destinos admitidos

Puede enviar telemetría a cualquier plataforma de APM que exponga un extremo OTLP/HTTPS, lo que incluye:

  • New Relic
  • Dynatrace
  • Datadog
  • Grafana Cloud
  • Splunk Observability Cloud
  • Guión0
  • Panal
  • Observabilidad elástica
  • Lógica de sumo
  • ServiceNow Cloud Observability

Esta lista no es exhaustiva. OpenTelemetry define el formato de telemetría y el protocolo de exportación, y la plataforma seleccionada determina cómo se consultan, visualizan, retienen y alertan los datos.

Elegir una plataforma de observabilidad

Necesita una plataforma que acepte OTLP/HTTPS para recibir la telemetría. Adobe no lo proporciona, debe traer su propia plataforma de observabilidad.

Si su organización ya utiliza una de las plataformas anteriores, comience por allí. Si no es así, elija entre una plataforma alojada por el proveedor (SaaS) y una autoalojada:

Alojado por el proveedor (SaaS)
Autoalojado
Configuración
No hay nada que instalar ni operar.
Puede instalar, actualizar y escalar la plataforma.
Ubicación de datos
La telemetría abandona su entorno y puede necesitar una revisión de seguridad o privacidad.
La telemetría permanece en la infraestructura que controla.
Funciones
Las vistas Paneles, Alertas y APM suelen estar integradas. Algunas funciones son específicas del proveedor.
Las funciones dependen del software que elija.
Costo
El precio suele depender del volumen de datos.
Usted paga por la infraestructura y el tiempo de ingeniería.
Disponibilidad
El proveedor administra el servicio.
Puede administrar el tiempo de actividad, el almacenamiento, los backups y la retención.

Antes de comenzar

  • Entornos: puede habilitar OpenTelemetry individualmente en entornos de producción, ensayo y desarrollo. Sin embargo, los entornos con ámbito HIPAA, los programas de zonas protegidas y los entornos de desarrollo rápido (RDE) NO son compatibles.
  • Versiones: la integración admite OpenTelemetry Java agent 2.x y el protocolo de exportación OTLP/HTTPS.

Próximos pasos

Siga el tutorial de configuración para configurar OpenTelemetry con el proyecto de muestra WKND de AEM o su propio proyecto AEM.

Recursos adicionales

recommendation-more-help
experience-manager-learn-help-cloud-service