OpenTelemetry per AEM opentelemetry-apm

Adobe sta sostituendo l’integrazione di Application Performance Monitoring (APM) integrata in AEM as a Cloud Service con OpenTelemetry, un approccio aperto e basato su standard di settore all’osservabilità supportato da ogni piattaforma di monitoraggio principale.

Oggi, AEM as a Cloud Service include un’integrazione APM integrata, gestita interamente da Adobe. Quando questa integrazione verrà sostituita, sarà necessario inserire il proprio endpoint APM, ovvero una piattaforma del fornitore che accetta dati OpenTelemetry o un back-end con hosting autonomo (on-premise) compatibile con OpenTelemetry.

Vantaggi di questa modifica benefits

Panoramica overview

AEM as a Cloud Service può emettere telemetria dalla tua applicazione utilizzando OpenTelemetry, un approccio aperto e basato su standard di settore all’osservabilità, e inoltrarla al provider APM desiderato. Questo consente di monitorare l’applicazione AEM insieme al resto dei sistemi, negli strumenti già utilizzati dai team.

I motivi comuni per utilizzare questa integrazione includono l’analisi delle richieste lente o in errore, il tracciamento nel tempo dello stato e dell’utilizzo delle risorse JVM, la creazione di dashboard e avvisi per i livelli AEM e la correlazione del comportamento di AEM con gli altri servizi durante un incidente, il tutto senza uscire dagli strumenti di monitoraggio già utilizzati dai team.

L’ambito della telemetria è il seguente:

L’inoltro del registro continua a essere supportato tramite il meccanismo separato esistente e non è interessato da questa integrazione.

Per scoprire come funziona, tra cui come la telemetria scorre da AEM alla piattaforma APM, cosa controlli e come scegliere una piattaforma, consulta l’esercitazione Osservabilità tramite OpenTelemetry.

Versioni di OpenTelemetry supportate supported-versions

L’agente OpenTelemetry viene eseguito come parte del runtime di Cloud Service. Adobe lo fornisce e lo mantiene aggiornato, pertanto non è necessario installarlo, gestirlo o aggiornarlo. La versione della patch specifica può cambiare con l’aggiornamento dell’agente da parte di Adobe.

Varianti OpenTelemetry supportate supported-variants

L’applicazione AEM può essere dotata di strumenti con una delle seguenti varianti dell’agente OpenTelemetry (distribuzioni), tutte basate sulla versione precedente. Per informazioni dettagliate, consulta la documentazione di ciascun progetto:

La variante a monte predefinita funziona con qualsiasi fornitore APM. Le varianti Grafana e Splunk aggiungono la strumentazione specifica del fornitore e i valori predefiniti per tali piattaforme. Adobe installa la variante dell’agente selezionata nel contenitore AEM al momento della distribuzione. Durante la disponibilità limitata, la variante a monte viene utilizzata per impostazione predefinita; per utilizzare la variante Grafana o Splunk, richiedila quando richiedi l’accesso. Il file config/otel.yaml configura dove va la telemetria; non dispone di un campo per selezionare la variante dell’agente.

fornitori APM apm-vendors

Puoi inviare la tua telemetria a qualsiasi fornitore di Monitoraggio delle prestazioni delle applicazioni che accetta dati OpenTelemetry su OTLP/HTTPS. Questo è indipendente dalla variante OpenTelemetry scelta. I fornitori con supporto OTLP/HTTPS includono:

Questo elenco non è esaustivo: è possibile utilizzare qualsiasi back-end che espone un endpoint OTLP/HTTPS.

Ambienti supportati supported-environments

Puoi abilitare questa integrazione negli ambienti di produzione, fase e sviluppo di Cloud Manager. Ogni ambiente è abilitato singolarmente. Vedere Passaggio 1. Gli ambienti di sviluppo rapido (RDE) non sono supportati.

Integrazioni APM esistenti existing-apm

OpenTelemetry non può essere eseguito insieme a un altro agente APM nello stesso ambiente:

Connettività di rete network-connectivity

L’endpoint del provider APM deve essere raggiungibile dall’ambiente AEM as a Cloud Service tramite HTTPS.

Se l’endpoint APM è privato o se è necessario che il traffico in uscita lasci un indirizzo IP stabile e noto, questa integrazione supporta Rete avanzata con uscita dedicata. Per informazioni su come abilitarlo, vedere Rete avanzata.

Quali dati vengono inviati what-data-is-sent

Solo i registri di tracce, metriche e (se abilitati) generati dall’applicazione AEM vengono inviati al provider APM. Gli esempi seguenti illustrano il tipo di dati che è possibile prevedere.

Tracce — espande le richieste gestite dall’applicazione, tra cui:

Le attività di pianificazione interna e di valutazione dello stato di salute (ad esempio, i lavori al quarzo) vengono filtrate in modo che le tracce rimangano concentrate sulle richieste delle applicazioni.

Metriche — Metriche del runtime JVM e del server HTTP, utilizzando i nomi delle metriche OpenTelemetry standard, e metriche AEM sotto il prefisso aem. (rollout in corso. Vengono visualizzate automaticamente, senza modifiche alla configurazione), tra cui:

Registri: le voci di registro dell’applicazione AEM al livello WARN e superiore, inviate utilizzando il segnale dei registri di OpenTelemetry, se abilitate. La possibilità di regolare questo livello di registro è in fase di sviluppo. Le voci di registro contengono gli stessi attributi di risorsa delle tracce e delle metriche (service.name, deployment.environment) e gli identificatori di traccia e span della richiesta che le ha generate, in modo che possano essere correlati con le tracce.

I registri inviati in questo modo sono indipendenti da Inoltro log. Per informazioni sul motivo per cui l’abilitazione di entrambi nella stessa destinazione causa duplicati, vedere Panoramica.

Identificazione della telemetria: ogni traccia e metrica include attributi di risorse che identificano la relativa origine, tra cui:

Le informazioni sul runtime di Cloud Service e sulla piattaforma che ospita l’applicazione, ad esempio nomi host interni, indirizzi, identificatori dei contenitori e dettagli del sistema operativo o del processo, vengono rimosse prima che i dati lascino l’ambiente.

Configurare l’integrazione set-up

Per una procedura guidata che utilizza il progetto di esempio WKND, dall’archiviazione delle credenziali in Cloud Manager alla verifica della telemetria nella piattaforma di osservabilità, vedere l’esercitazione Configurazione di OpenTelemetry per approfondimenti sulle applicazioni AEM.

Passaggio 1: richiedere l’accesso request-access

Invia un’e-mail a aemcs-apm-beta@adobe.com con l’ID del programma Cloud Manager e gli ID dell’ambiente che desideri abilitare. Se desideri utilizzare la variante dell’agente Grafana o Splunk invece del valore predefinito, lo dica nell’e-mail (vedi Varianti OpenTelemetry supportate).

Adobe abilita OpenTelemetry per tali ambienti subito dopo aver risposto alla richiesta. Se un ambiente utilizza attualmente l’integrazione APM integrata di Adobe, tale integrazione interrompe l’invio di dati una volta abilitata OpenTelemetry. Vedere Integrazioni APM esistenti.

Passaggio 2: aggiungi il file di configurazione add-configuration

Aggiungi un file config/otel.yaml all’archivio della pipeline di configurazione di Cloud Manager. Specifica almeno:

Vedi Esempio di configurazione di seguito per il formato di file esatto, inclusi esempi per New Relic, Dynatrace, Grafana Cloud, Splunk, Datadog, Dash0 ed endpoint generici o self-hosted.

Passaggio 3: configurare le credenziali di autenticazione configure-credential

Fornire le credenziali richieste dal provider APM dichiarando una variabile di ambiente segreta denominata OTEL_CUSTOMER_AUTH in Cloud Manager. Imposta Servizio applicato su Tutti in modo che le credenziali siano disponibili per i livelli di authoring, pubblicazione e anteprima.

Per aggiungere o aggiornare le variabili di ambiente, è necessario essere membri del ruolo Responsabile della distribuzione. Per la procedura completa, vedere Variabili di ambiente in Cloud Manager.

Imposta il valore in base al metodo di autenticazione del provider:

Impostazioni specifiche del provider provider-specific

Nella tabella seguente vengono riepilogati l’endpoint e l’autenticazione per alcuni provider comuni. Conferma sempre i valori correnti nella documentazione del provider. Per i provider che utilizzano un’intestazione personalizzata (ad esempio, New Relic e Datadog), impostare OTEL_CUSTOMER_AUTH solo sul valore di chiave non elaborata e impostare authHeaderName nel file di configurazione sul nome di intestazione corretto (vedere Esempio di configurazione).

Esempio di configurazione example-configuration

Aggiungi un file come uno degli esempi seguenti a config/otel.yaml nell’archivio della pipeline di configurazione, in base al provider dalle impostazioni specifiche del provider.

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

Trattino0:

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 (tramite una distribuzione Splunk dell’agente di raccolta OpenTelemetry in esecuzione come 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

Endpoint generico o self-hosted (ad esempio, un raccoglitore OpenTelemetry locale):

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

Rete avanzata (uscita dedicata) — per un endpoint privato o per un endpoint che richiede la partenza del traffico da un indirizzo IP noto e stabile (vedere Connettività di rete):

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

Passaggio 4: distribuire deploy

Dopo aver confermato che OpenTelemetry è abilitato per l’ambiente (vedi Passaggio 1), esegui la pipeline di configurazione per distribuire config/otel.yaml. La pipeline convalida la configurazione e controlla l’endpoint e le credenziali prima di applicarla, pertanto la maggior parte degli errori viene segnalata direttamente nel registro della pipeline.

Al termine della pipeline, le tracce, le metriche e i registri (se abilitati) dell’applicazione AEM iniziano a essere visualizzati nel provider APM. Utilizza Passaggio 5 per confermare.

Passaggio 5: verificare l’integrazione verify

Poiché la telemetria viene inviata al provider APM, l’utente conferma l’integrazione dagli strumenti del provider; Adobe non restituisce questi dati all’utente.

Al termine della pipeline, attendi alcuni minuti prima che i dati arrivino, quindi controlla il provider APM per verificare che:

Se questi dati vengono visualizzati, l’integrazione funziona.

Risoluzione di problemi troubleshooting

Se la telemetria non viene visualizzata nel provider APM, verificare quanto segue:

Se dopo questi controlli la telemetria non viene ancora visualizzata, contattare aemcs-apm-beta@adobe.com con i dettagli del programma e dell’ambiente.

Domande frequenti faq

Perché sta avvenendo questa modifica?

I clienti di AEM as a Cloud Service hanno richiesto ulteriori metriche e dati operativi, nonché tracce, espansioni e registri nel contesto. OpenTelemetry è uno standard di settore che supporta tutte queste funzionalità e le produce in un formato ampiamente supportato (OTLP).

È necessario richiedere l’accesso?

Sì. Durante la disponibilità limitata, invia un’e-mail a aemcs-apm-beta@adobe.com con gli ID del programma e dell’ambiente. Adobe abilita OpenTelemetry per tali ambienti subito dopo aver risposto alla richiesta. Questo non è ancora disponibile per gli ambienti con ambito HIPAA.

Cosa succede a New Relic se si abilita OpenTelemetry?

Una volta che Adobe abilita OpenTelemetry per un ambiente su richiesta, i dati non vengono più inviati a New Relic da tale ambiente. I due elementi non possono essere eseguiti contemporaneamente.

Se eseguo la migrazione a OpenTelemetry da New Relic, posso tornare indietro?

Sì. Invia e-mail a aemcs-apm-beta@adobe.com e Adobe disabilita OpenTelemetry per i tuoi ambienti. Quindi imposta enabled: false nel file config/otel.yaml (o rimuovi il file), esegui la pipeline di configurazione ed esegui una pipeline full stack fino al completamento per ripristinare New Relic. Ciò è possibile fino alla fine di novembre 2026.

È possibile utilizzare OpenTelemetry se l’ambiente esegue Dynatrace OneAgent?

Non nello stesso ambiente: Dynatrace OneAgent ha la precedenza. È possibile rimuovere OneAgent e utilizzare invece OpenTelemetry, anche con Dynatrace come provider APM. Consulta Integrazioni APM esistenti.

Cosa succede dopo novembre 2026?

Adobe passerà dalla soluzione APM integrata a OpenTelemetry come soluzione di osservabilità permanente.

Articoli correlati related-articles