OpenTelemetry pour AEM opentelemetry-apm

Adobe remplace l’intégration de surveillance des performances des applications (APM) intégrée à AEM as a Cloud Service par OpenTelemetry, une approche ouverte et standard de l’observabilité prise en charge par chaque plateforme de surveillance majeure.

Aujourd’hui, AEM as a Cloud Service comprend une intégration APM intégrée, entièrement gérée par Adobe. À mesure que cette intégration sera remplacée, vous devrez apporter votre propre point d’entrée APM, soit une plateforme fournisseur qui accepte les données OpenTelemetry, soit un serveur principal auto-hébergé (sur site) compatible avec OpenTelemetry.

Avantages de cette modification benefits

Vue d’ensemble overview

AEM as a Cloud Service peut émettre de la télémétrie à partir de votre application à l’aide d’OpenTelemetry, une approche ouverte et standard de l’observabilité, et la transférer au fournisseur APM de votre choix. Vous pouvez ainsi surveiller votre application AEM aux côtés du reste de vos systèmes, dans les outils déjà utilisés par vos équipes.

Les raisons courantes d’utiliser cette intégration incluent l’analyse des requêtes lentes ou en échec, le suivi de l’intégrité et de l’utilisation des ressources JVM au fil du temps, la création de tableaux de bord et d’alertes pour vos niveaux AEM et la corrélation du comportement d’AEM avec le reste de vos services lors d’un incident, le tout sans quitter les outils de surveillance que vos équipes utilisent déjà.

La télémétrie suivante est concernée :

Le transfert de journal continue d’être pris en charge par son mécanisme distinct existant et n’est pas affecté par cette intégration.

Pour en savoir plus sur son fonctionnement, notamment sur le flux de télémétrie d’AEM vers votre plateforme APM, ce que vous contrôlez et comment choisir une plateforme, consultez le tutoriel Observability via OpenTelemetry.

Versions OpenTelemetry prises en charge supported-versions

L’agent OpenTelemetry s’exécute dans le cadre de l’exécution de Cloud Service. Adobe le fournit et le tient à jour, de sorte que vous n’avez pas besoin de l’installer, de le gérer ou de le mettre à niveau vous-même. La version spécifique du correctif peut changer à mesure qu’Adobe met à jour l’agent.

Variantes OpenTelemetry prises en charge supported-variants

Votre application AEM peut être instrumentée avec l’une des variantes (distributions) d’agent OpenTelemetry suivantes, toutes basées sur la version ci-dessus. Voir la documentation de chaque projet pour plus de détails :

La variante en amont par défaut fonctionne avec n’importe quel fournisseur APM. Les variantes Grafana et Splunk ajoutent une instrumentation et des valeurs par défaut spécifiques au fournisseur pour ces plateformes. Adobe installe la variante d’agent sélectionnée dans le conteneur AEM au moment du déploiement. Pendant la disponibilité limitée, la variante en amont est utilisée par défaut ; pour utiliser la variante Grafana ou Splunk, demandez-la lorsque vous demandez l’accès. Le fichier config/otel.yaml configure l’emplacement de la télémétrie ; il n’a pas de champ pour sélectionner la variante de l’agent.

Fournisseurs APM apm-vendors

Vous pouvez envoyer votre télémétrie à tout fournisseur de surveillance des performances des applications qui accepte les données OpenTelemetry via OTLP/HTTPS. Cela est indépendant de la variante OpenTelemetry que vous choisissez. Les fournisseurs prenant en charge OTLP/HTTPS sont les suivants :

Cette liste n’est pas exhaustive : tout serveur principal qui expose un point d’entrée OTLP/HTTPS peut être utilisé.

Environnements pris en charge supported-environments

Vous pouvez activer cette intégration dans vos environnements Cloud Manager de production, d’évaluation et de développement. Chaque environnement est activé individuellement (voir Étape 1). Les environnements de développement rapide (RDE) ne sont pas pris en charge.

Intégrations APM existantes existing-apm

OpenTelemetry ne peut pas s’exécuter avec un autre agent APM sur le même environnement :

Connectivité réseau network-connectivity

Le point d’entrée de votre fournisseur APM doit être accessible à partir de votre environnement AEM as a Cloud Service via HTTPS.

Si votre point d’entrée APM est privé ou si vous avez besoin que le trafic sortant sorte d’une adresse IP stable et connue, cette intégration prend en charge la mise en réseau avancée avec sortie dédiée. Voir Mise en réseau avancée pour savoir comment l’activer.

Les données envoyées what-data-is-sent

Seules les traces, mesures et (si activés) journaux générés par votre application AEM sont envoyés à votre fournisseur APM. Les exemples suivants illustrent le type de données auxquelles vous pouvez vous attendre.

Traces : couvre les requêtes traitées par votre application, notamment :

Le planificateur interne à volume élevé et l’activité d’analyse de l’intégrité (par exemple, les tâches Quartz) sont filtrés afin que les traces restent concentrées sur les requêtes d’application.

Mesures — Mesures de l’exécution JVM et du serveur HTTP, à l’aide des noms de mesures OpenTelemetry standard, et mesures AEM sous le préfixe aem. (en cours de déploiement ; elles s’affichent automatiquement, sans modification de configuration), notamment :

Journaux : les entrées de journal de votre application AEM au niveau WARN et supérieur, envoyées à l’aide du signal de journaux d’OpenTelemetry, lorsqu’elles sont activées. La possibilité d’ajuster ce niveau de journalisation est en cours de développement. Les entrées de journal portent les mêmes attributs de ressource que les traces et les mesures (service.name, deployment.environment), ainsi que les identifiants de trace et d’étendue de la requête qui les a produites, afin qu’ils puissent être corrélés aux traces.

Les journaux envoyés de cette manière sont indépendants du transfert de journal — consultez Présentation pour savoir pourquoi l’activation des deux vers la même destination entraîne des doublons.

Identification de la télémétrie — Chaque trace et chaque mesure comporte des attributs de ressource qui identifient sa source, notamment :

Les informations sur le runtime Cloud Service et la plateforme qui héberge votre application, telles que les noms d’hôtes internes, les adresses, les identifiants de conteneur et les détails du système d’exploitation ou du processus, sont supprimées avant que les données ne quittent votre environnement.

Configuration de l’intégration set-up

Pour une présentation guidée qui utilise l’exemple de projet WKND, du stockage de vos informations d’identification dans Cloud Manager à la vérification de la télémétrie dans votre plateforme d’observabilité, consultez le tutoriel Configurer OpenTelemetry pour obtenir des informations sur les applications AEM.

Étape 1 : Demander l’accès request-access

Envoyez un courrier électronique à l’adresse 🔗 avec votre ID de programme Cloud Manager et les ID d’environnement à activer. Si vous souhaitez utiliser la variante de l’agent Grafana ou Splunk plutôt que la valeur par défaut, indiquez-le dans votre e-mail (voir Variantes OpenTelemetry prises en charge).

Adobe active OpenTelemetry pour ces environnements peu de temps après avoir répondu à votre demande. Si un environnement utilise actuellement l’intégration APM intégrée d’Adobe, cette intégration cesse d’envoyer des données une fois que OpenTelemetry est activé. Reportez-vous à la section ​ Intégrations APM existantes ​.

Étape 2 : ajouter votre fichier de configuration add-configuration

Ajoutez un fichier config/otel.yaml au référentiel du pipeline de configuration Cloud Manager. Spécifiez au minimum les éléments suivants :

Voir Exemple de configuration ci-dessous pour le format de fichier exact, y compris des exemples pour New Relic, Dynatrace, Grafana Cloud, Splunk, Datadog, Dash0 et les points d’entrée génériques ou auto-hébergés.

Étape 3 : configurer vos informations d’authentification configure-credential

Fournissez les informations d’identification dont votre fournisseur APM a besoin en déclarant une variable d’environnement secrète nommée OTEL_CUSTOMER_AUTH dans Cloud Manager. Définissez Service appliqué sur Tous afin que les informations d’identification soient disponibles pour les niveaux de création, de publication et de prévisualisation.

Pour ajouter ou mettre à jour des variables d’environnement, vous devez être membre du rôle Responsable de déploiement. Pour la procédure complète, voir Variables d’environnement dans Cloud Manager.

Définissez la valeur en fonction de la méthode d’authentification de votre fournisseur :

Paramètres spécifiques au fournisseur provider-specific

Le tableau suivant résume le point d’entrée et l’authentification pour certains fournisseurs courants. Confirmez toujours les valeurs actuelles dans la documentation de votre fournisseur. Pour les fournisseurs qui utilisent un en-tête personnalisé (par exemple, New Relic et Datadog), définissez OTEL_CUSTOMER_AUTH sur la valeur de clé brute uniquement, puis définissez authHeaderName dans votre fichier de configuration sur le nom d’en-tête correct (voir Exemple de configuration).

Exemple de configuration example-configuration

Ajoutez un fichier tel que l’un des exemples suivants à config/otel.yaml dans votre référentiel de pipeline de configuration, en fonction de votre fournisseur à partir des paramètres spécifiques au fournisseur.

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 (par le biais d’une distribution Splunk du collecteur OpenTelemetry s’exécutant en tant que passerelle) :

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

Point d’entrée générique ou auto-hébergé (par exemple, un collecteur 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

Mise en réseau avancée (sortie dédiée) — pour un point d’entrée privé, ou qui nécessite que le trafic sorte d’une adresse IP stable et connue (voir Connectivité réseau) :

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

Étape 4 : Déployer deploy

Une fois qu’Adobe a confirmé qu’OpenTelemetry est activé pour votre environnement (voir Étape 1), exécutez votre pipeline de configuration pour déployer config/otel.yaml. Le pipeline valide votre configuration et vérifie votre point d’entrée et vos informations d’identification avant d’appliquer la configuration. La plupart des erreurs sont donc signalées directement dans le journal du pipeline.

Une fois le pipeline terminé, les traces, les mesures et les journaux (s’ils sont activés) de votre application AEM commencent à apparaître dans votre fournisseur APM. Utilisez Étape 5 pour confirmer.

Étape 5 : vérifier l’intégration verify

Comme la télémétrie est envoyée à votre propre fournisseur APM, vous confirmez l’intégration à partir des outils de votre fournisseur ; Adobe ne vous renvoie pas ces données.

Une fois le pipeline terminé, patientez quelques minutes le temps que les données arrivent, puis vérifiez les points suivants auprès de votre fournisseur APM :

Si ces données apparaissent, l’intégration fonctionne.

Résolution des problèmes troubleshooting

Si la télémétrie n’apparaît pas dans votre fournisseur APM, vérifiez les points suivants :

Si la télémétrie n’apparaît toujours pas après ces vérifications, contactez 🔗 en fournissant les détails de votre programme et de votre environnement.

FAQ faq

Pourquoi ce changement se produit-il ?

Les clients AEM as a Cloud Service ont demandé des mesures et des données opérationnelles supplémentaires, ainsi que des traces, des étendues et des journaux en contexte. OpenTelemetry est une norme du secteur qui prend en charge toutes ces fonctionnalités et les génère dans un format largement pris en charge (OTLP).

Dois-je demander l’accès ?

Oui. Pendant la disponibilité limitée, envoyez un e-mail à 🔗 avec vos ID de programme et d’environnement. Adobe active OpenTelemetry pour ces environnements peu de temps après avoir répondu à votre demande. Cette option n’est pas encore disponible pour les environnements soumis à la loi HIPAA.

Qu’advient-il de New Relic si j’active OpenTelemetry ?

Une fois qu’Adobe active OpenTelemetry pour un environnement à votre demande, les données ne sont plus envoyées à New Relic à partir de cet environnement. Les deux ne peuvent pas fonctionner en même temps.

Si je migre vers OpenTelemetry à partir de New Relic, puis-je revenir en arrière ?

Oui. Envoyez un e-mail à 🔗 et Adobe désactive OpenTelemetry pour vos environnements. Ensuite, définissez enabled: false dans votre fichier config/otel.yaml (ou supprimez le fichier), exécutez votre pipeline de configuration et exécutez un pipeline de pile complète pour terminer la restauration de New Relic. Cela est possible jusqu’à la fin novembre 2026.

Puis-je utiliser OpenTelemetry si mon environnement exécute Dynatrace OneAgent ?

Pas sur le même environnement : Dynatrace OneAgent est prioritaire. Vous pouvez supprimer OneAgent et utiliser OpenTelemetry à la place, y compris avec Dynatrace comme fournisseur APM. Voir ​ Intégrations APM existantes ​.

Que se passe-t-il après novembre 2026 ?

Adobe passera de sa solution APM intégrée à OpenTelemetry en tant que solution d’observabilité permanente.

Articles connexes related-articles