OpenTelemetry (Beta) opentelemetry-apm

Adobe ersetzt die in AEM as a Cloud Service integrierte APM-Integration (Application Performance Monitoring) durch OpenTelemetry, einen offenen, branchenüblichen Ansatz zur Beobachtung, der von jeder wichtigen Überwachungsplattform unterstützt wird.

Heute umfasst AEM as a Cloud Service eine integrierte APM-Integration, die vollständig von Adobe verwaltet wird. Wenn diese Integration ersetzt wird müssen Sie Ihren eigenen APM-Endpunkt mitbringen entweder eine Anbieterplattform, die OpenTelemetry-Daten akzeptiert, oder ein selbst gehostetes (On-Premise-)OpenTelemetry-kompatibles Backend.

Vorteile dieser Änderung benefits

Überblick overview

AEM as a Cloud Service kann mithilfe von OpenTelemetry, einem offenen, dem Industriestandard entsprechenden Ansatz zur Beobachtung, Telemetrie aus Ihrer Anwendung aussenden und an einen APM-Anbieter Ihrer Wahl weiterleiten. Auf diese Weise können Sie Ihre AEM-Anwendung zusammen mit den anderen Systemen in den Tools überwachen, die Ihre Teams bereits verwenden.

Häufige Gründe für die Verwendung dieser Integration sind die Untersuchung langsamer oder fehlgeschlagener Anfragen, die Verfolgung des JVM-Status und der Ressourcennutzung im Laufe der Zeit, die Erstellung von Dashboards und Warnhinweisen für Ihre AEM-Ebenen und die Korrelation des AEM-Verhaltens mit dem Rest Ihrer Services während eines Vorfalls - und das alles, ohne die Überwachungs-Tools zu verlassen, die Ihre Teams bereits verwenden.

Die folgende Telemetrie ist im Umfang enthalten:

​* Traces - verteilte Traces von Anfragen, die von Ihrer AEM-Anwendung verarbeitet werden.
​* Metriken - Anwendungsmetriken wie JVM-Laufzeitmetriken (Arbeitsspeicher, Speicherbereinigung, Threads) und Raten eingehender HTTP-Anfragen, Latenzen und Fehlerraten.
​* Protokolle - die Protokolle Ihrer AEM-Anwendung, die mithilfe des OpenTelemetry-Protokollsignals gesendet werden. Protokolle sind optional und können unabhängig von Ablaufverfolgungen und Metriken umgeschaltet werden.

Protokollweiterleitung wird über den vorhandenen, separaten Mechanismus weiterhin unterstützt und ist von dieser Integration nicht betroffen.

Unterstützte OpenTelemetry-Versionen supported-versions

Der OpenTelemetry-Agent wird als Teil der Cloud Service-Laufzeit ausgeführt. Adobe stellt es bereit und hält es auf dem neuesten Stand, sodass Sie es nicht selbst installieren, verwalten oder aktualisieren müssen. Die spezifische Patch-Version kann sich ändern, wenn Adobe den Agenten aktualisiert.

Unterstützte OpenTelemetry-Varianten supported-variants

Ihre AEM-Anwendung kann mit einer der folgenden OpenTelemetry-Agentvarianten (Distributionen) instrumentiert werden, die alle auf der obigen Version basieren. Wählen Sie die Variante aus, die zu Ihren Tools passt. Weitere Informationen finden Sie in der Dokumentation jedes Projekts:

Die standardmäßige Upstream-Variante funktioniert mit jedem APM-Anbieter. Die Varianten Grafana und Splunk fügen herstellerspezifische Instrumentierung und Standardwerte für diese Plattformen hinzu.

APM-Anbieter apm-vendors

Sie können Ihre Telemetrie an einen beliebigen Anbieter für die Anwendungsleistungsüberwachung senden, der OpenTelemetry-Daten über OTLP/HTTPS akzeptiert. Dies ist unabhängig von der ausgewählten OpenTelemetry-Variante. Zu den Anbietern mit OTP-/HTTPS-Unterstützung gehören:

​* New Relic
​* Grafana Cloud
​* Splunk Observability Cloud
​* Dynatrace
​* Datadog
​* DASH0
​* Honigwabe
​* elastische Beobachtbarkeit
​* Sumo Logic
​* ServiceNow-Cloud-Beobachtbarkeit

Diese Liste ist nicht vollständig. Es können alle Backends verwendet werden, die einen OTP/HTTPS-Endpunkt bereitstellen.

Unterstützte Umgebungen supported-environments

Sie können diese Integration in Ihren Cloud Manager-Umgebungen Produktion, Staging und Entwicklung aktivieren. Jede Umgebung wird einzeln aktiviert - siehe Schritt 1. Schnelle Entwicklungsumgebungen (RDE) werden nicht unterstützt.

Netzwerkkonnektivität network-connectivity

Der Endpunkt Ihres APM-Anbieters muss über HTTPS von Ihrer AEM as a Cloud Service-Umgebung aus erreichbar sein.

Wenn Ihr APM-Endpunkt privat ist oder Sie ausgehenden Traffic benötigen, um von einer stabilen, bekannten IP-Adresse zu verlassen, unterstützt diese Integration erweiterte Vernetzung mit dediziertem Ausgang. Informationen ​ Aktivieren finden ​ unter „Erweiterte Netzwerke“.

Welche Daten gesendet werden what-data-is-sent

Nur die von Ihrer AEM-Anwendung) generierten Traces, Metriken und (falls aktiviert Protokolle werden an Ihren APM-Anbieter gesendet. Die folgenden Beispiele veranschaulichen die Art der Daten, die Sie erwarten können.

Traces - umfasst die von Ihrem Programm verarbeiteten Anfragen, darunter:

​* Eingehende HTTP-Anfragen erstrecken sich über einen Zeitraum hinweg und sind nach Methode und Route benannt (z. B. GET /content/...).
​* Das Servlet und die ausgehende Datenbank (JDBC) erstrecken sich über , die während der Verarbeitung einer Anfrage generiert werden.

Interner Scheduler mit hohem Volumen und Aktivitäten mit Integritätsprüfungen (z. B. Quartz-Aufträge) werden herausgefiltert, damit die Verfolgung sich auf die Anwendungsanfragen konzentriert. Detaillierte AEM-Framework-interne Bereiche - wie Sling-Ressourcenauflösung, OSGi-Services oder JCR-Zugriff - werden in dieser Version nicht ausgegeben.

Metriken - JVM-Laufzeit- und HTTP-Server-Metriken, die standardmäßige OpenTelemetry-Metriknamen verwenden, darunter:

​* JVM-Laufzeit: jvm.memory.used, jvm.gc.duration, jvm.thread.count und jvm.cpu.recent_utilization.
​* HTTP-Server: http.server.request.duration (Anfragerate, Latenzperzentile und Fehlerrate werden aus diesem Histogramm abgeleitet).

Protokolle - Die Protokolleinträge Ihrer AEM-Anwendung, die mit dem Protokollsignal von OpenTelemetry gesendet werden, wenn sie aktiviert sind. Protokolleinträge enthalten dieselben Ressourcenattribute wie Traces und Metriken (service.name, deployment.environment), sodass sie mit ihnen korreliert werden können.

Auf diese Weise gesendete Protokolle sind unabhängig von Protokollweiterleitung - warum die Aktivierung beider Protokolle für dasselbe Ziel zu Duplikaten führt, ​ Sie unter Übersicht.

Wie die Telemetrie identifiziert wird - Jede Ablaufverfolgung und Metrik enthält Ressourcenattribute, die ihre Quelle identifizieren, darunter:

​* service.name - Identifiziert Ihr Programm, Ihre Umgebung, Ihren Service und Ihre Ebene (z. B. cm-p<program>-e<environment>-aem-publish-prod).
​* deployment.environment - Der Umgebungstyp (z. B. prod oder stage).

Informationen zur Cloud Service-Laufzeit und der Plattform, auf der Ihre Anwendung gehostet wird, z. B. interne Hostnamen, Adressen, Container-IDs und Betriebssystem- oder Prozessdetails, werden entfernt, bevor Daten Ihre Umgebung verlassen.

Einrichten der Integration set-up

Schritt 1: Integration aktivieren request-access

Fügen Sie eine config/otel.yaml-Datei zu Ihrem Cloud Manager Config Pipeline-Repository hinzu. Geben Sie mindestens Folgendes an:

​* Die Umgebungstypen, für die diese Konfiguration gilt (z. B. stage und prod).
​* Typ Ihres APM-Anbieters und OTP/HTTPS-Endpunkt-URL (einschließlich Region, falls zutreffend).
​* Die Authentifizierungsmethode, die Ihr Anbieter verwendet (siehe Schritt 2).

Siehe Beispielkonfiguration unten für das genaue Dateiformat, einschließlich Beispielen für New Relic, Dynatrace, Datadog, Dash0 und generische oder selbst gehostete Endpunkte.

Schritt 2: Authentifizierungsberechtigungen konfigurieren configure-credential

Geben Sie die Anmeldeinformationen an, die Ihr APM-Anbieter benötigt, indem Sie eine geheime Umgebungsvariable namens OTEL_CUSTOMER_AUTH in Cloud Manager deklarieren. Legen Sie Service angewendet auf Alle fest, damit die Berechtigung für die Autoren-, Veröffentlichungs- und Vorschauebenen verfügbar ist.

Um Umgebungsvariablen hinzuzufügen oder zu aktualisieren, müssen Sie Mitglied der Rolle Bereitstellungs-Manager“ ​. Eine vollständige Anleitung finden Sie unter Umgebungsvariablen in Cloud Manager.

Legen Sie den Wert entsprechend der Authentifizierungsmethode Ihres Anbieters fest:

Anbieterspezifische Einstellungen provider-specific

In der folgenden Tabelle sind der Endpunkt und die Authentifizierung für einige gängige Anbieter zusammengefasst. Bestätigen Sie stets die aktuellen Werte in der Dokumentation Ihres Anbieters. Setzen Sie bei Anbietern, die eine benutzerdefinierte Kopfzeile verwenden (z. B. New Relic und Datadog), OTEL_CUSTOMER_AUTH auf den reinen Schlüsselwert und setzen Sie authHeaderName in Ihrer Konfigurationsdatei auf den richtigen Kopfzeilennamen (siehe Beispielkonfiguration).

Beispielkonfiguration example-configuration

Fügen Sie in Ihrem Konfigurations-Pipeline-Repository basierend auf Ihrem Provider aus (anbieterspezifische Einstellungen) eine Datei wie eine ​ folgenden Beispielen zum config/otel.yaml ​.

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

DASH0:

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

Generischer oder selbst gehosteter Endpunkt (z. B. ein On-Premise OpenTelemetry Collector):

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

Erweiterte Netzwerke (dedizierter Ausgang) - für einen privaten Endpunkt oder einen Endpunkt, für den Traffic von einer bekannten, stabilen IP-Adresse getrennt werden muss (siehe Netzwerkverbindung):

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

Schritt 3: Bereitstellen deploy

Die Integration wirkt sich auf die nächste -Bereitstellung Ihrer Umgebung aus d. h., wenn das nächste Mal eine Bereitstellungs-Pipeline für die -Umgebung in Cloud Manager ausgeführt wird (z. B. eine Full-Stack-Bereitstellung). Wenn Ihre Umgebung seit dem Hinzufügen der config/otel.yaml-Datei und dem Festlegen der Anmeldeinformationen nicht bereitgestellt wurde, führen Sie zur Aktivierung eine Bereitstellung aus.

Nach der Bereitstellung werden Traces, Metriken und (falls aktiviert) Protokolle aus Ihrer AEM-Anwendung in Ihrem APM-Provider angezeigt. Verwenden Sie Schritt 4 zur Bestätigung.

Schritt 4: Integration überprüfen verify

Da die Telemetrie an Ihren eigenen APM-Provider gesendet wird, bestätigen Sie die Integration über die Tools Ihres Providers. Adobe übermittelt diese Daten nicht an Sie zurück.

Warten Sie nach Abschluss der Bereitstellung einige Minuten, bis die Daten eingegangen sind, und überprüfen Sie dann Ihren APM-Provider auf Folgendes:

​* Traces - neue Bereiche für Ihre AEM-Services. Suchen Sie beispielsweise nach dem service.name Ihrer Autoren- oder Veröffentlichungsebene oder nach den Bereichen eingehender HTTP-Anfragen.
​* Metriken - eingehende jvm.*- und http.server.* für Ihre Services.
​* Protokolle (falls aktiviert) - eingehende Protokolleinträge für Ihre AEM-Services.

Wenn diese Daten angezeigt werden, funktioniert die Integration.

Fehlerbehebung troubleshooting

Wenn bei Ihrem APM-Provider keine Telemetrie angezeigt wird, überprüfen Sie Folgendes:

Wenn nach diesen Prüfungen immer noch keine Telemetrie angezeigt wird, wenden Sie sich mit 🔗 Programm- und Umgebungsdetails an aemcs-apm-beta@adobe.com.

Häufig gestellte Fragen faq

Warum findet dieser Wandel statt?

AEM as a Cloud Service-Kunden haben im Kontext zusätzliche Metriken und Betriebsdaten sowie Traces, Spannen und Protokolle angefordert. OpenTelemetry ist ein Industriestandard, der alle diese Funktionen unterstützt und sie in einem weithin unterstützten Format (OTLP) ausgibt.

Was passiert mit New Relic, wenn ich OpenTelemetry aktiviere?

Wenn Sie die Konfigurations-Pipeline ausführen, werden Daten von AEM as a Cloud Service nicht mehr an New Relic übertragen.

Wenn ich von New Relic zu OpenTelemetry migriere, kann ich dann zurück?

Ja. Deaktivieren Sie OpenTelemetry über die Konfigurations-Pipeline und führen Sie dann eine Full-Stack-Pipeline bis zum Abschluss aus. Dies ist bis Ende November 2026 möglich.

Was passiert nach November 2026?

Adobe wird von seiner integrierten APM-Lösung zu OpenTelemetry als permanenter Beobachtungslösung übergehen.

Verwandte Artikel related-articles

​* Protokollweiterleitung
​* Erweiterte Netzwerkfunktionen konfigurieren
​* Umgebungsvariablen in Cloud Manager