OpenTelemetry (Beta) 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:

​* Tracce — tracce distribuite di richieste gestite dall’applicazione AEM.
​* Metriche: metriche dell’applicazione, ad esempio le metriche di runtime JVM (memoria, Garbage Collection, thread) e le percentuali di richieste HTTP in entrata, le latenze e le percentuali di errore.
​* Registri: i registri dell’applicazione AEM, inviati utilizzando il segnale dei registri di OpenTelemetry. I registri sono facoltativi e possono essere attivati indipendentemente da tracce e metriche.

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

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. Scegli la variante adatta ai tuoi strumenti; 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.

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:

​* New Relic
​* Grafana Cloud
​* Splunk Observability Cloud
​* Dynatrace
​* Datadog
​* Trattino0
​* favo d’ape
​* Osservabilità elastica
​* Logica sumo
​* Osservabilità ServiceNow Cloud

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.

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:

​* Intervalli di richieste HTTP in entrata, denominati per metodo e route (ad esempio, GET /content/...).
​* Le estensioni del servlet e del database in uscita (JDBC) vengono generate durante l’elaborazione di una richiesta.

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. In questa versione non vengono emessi span interni dettagliati al framework di AEM, come la risoluzione delle risorse Sling, i servizi OSGi o l’accesso JCR.

Metriche: metriche del runtime JVM e del server HTTP, utilizzando nomi di metriche OpenTelemetry standard, tra cui:

​* Runtime JVM: jvm.memory.used, jvm.gc.duration, jvm.thread.count e jvm.cpu.recent_utilization.
​* Server HTTP: http.server.request.duration (la frequenza di richieste, i percentili di latenza e la frequenza di errori sono derivati da questo istogramma).

Registri: le voci di registro dell’applicazione AEM, inviate utilizzando il segnale dei registri di OpenTelemetry, se abilitate. Le voci di registro contengono gli stessi attributi di risorsa delle tracce e delle metriche (service.name, deployment.environment), pertanto possono essere correlate con esse.

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:

​* service.name: identifica il programma, l’ambiente, il servizio e il livello (ad esempio, cm-p<program>-e<environment>-aem-publish-prod).
​* deployment.environment — tipo di ambiente (ad esempio, prod o stage).

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

Passaggio 1: abilitare l’integrazione request-access

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

​* I tipi di ambiente a cui si applica questa configurazione (ad esempio, stage e prod).
​* Tipo del provider APM e URL dell’endpoint OTLP/HTTPS (inclusa l’area geografica, se applicabile).
​* Il metodo di autenticazione utilizzato dal provider (vedere Passaggio 2).

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

Passaggio 2: 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: "v1"
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: "v1"
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: "v1"
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: "v1"
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

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

kind: "Otel"
version: "v1"
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: "v1"
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 3: distribuire deploy

L’integrazione ha effetto sulla distribuzione successiva dell’ambiente, ovvero la successiva esecuzione di una pipeline di distribuzione per l’ambiente in Cloud Manager (ad esempio, una distribuzione full stack). Se l’ambiente non è stato distribuito dopo l’aggiunta del file config/otel.yaml e l’impostazione delle credenziali, eseguire una distribuzione per attivarlo.

Dopo la distribuzione, le tracce, le metriche e (se abilitati) i registri dell’applicazione AEM iniziano a essere visualizzati nel provider APM. Utilizza Passaggio 4 per confermare.

Passaggio 4: 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 dell’implementazione, attendi alcuni minuti per l’arrivo dei dati, quindi controlla il provider APM per ottenere quanto segue:

​* Tracce — nuove estensioni per i servizi AEM. Ad esempio, cerca service.name del livello di authoring o pubblicazione o per intervalli di richieste HTTP in entrata.
​* Metriche — metriche jvm.* e http.server.* in arrivo per i servizi.
​* Registri (se abilitati): voci di registro in ingresso per i servizi AEM.

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).

Cosa succede a New Relic se si abilita OpenTelemetry?

Quando esegui la pipeline di configurazione, i dati a New Relic non vengono più trasmessi da AEM as a Cloud Service.

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

Sì. Disattiva OpenTelemetry tramite la pipeline di configurazione, quindi esegui una pipeline full stack fino al completamento. Ciò è possibile fino alla fine di novembre 2026.

Cosa succede dopo novembre 2026?

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

Articoli correlati related-articles

​* Inoltro del registro
​* Configurare reti avanzate
​* Variabili di ambiente in Cloud Manager