OpenTelemetry für AEM 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:

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

Informationen zur Funktionsweise, einschließlich des Flusses der Telemetrie von AEM auf Ihre APM-Plattform, der Steuerung und der Auswahl einer Plattform, finden Sie im Tutorial Observability via OpenTelemetry.

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. Einzelheiten finden Sie in der Dokumentation der einzelnen Projekte:

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. Adobe installiert die ausgewählte Agentenvariante bei der Bereitstellung im AEM-Container. Bei eingeschränkter Verfügbarkeit wird standardmäßig die Upstream-Variante verwendet. Um die Grafana- oder Splunk-Variante zu verwenden, fragen Sie bei der ​ nach ​. Die config/otel.yaml-Datei konfiguriert, wohin die Telemetrie geht; sie hat kein Feld zur Auswahl der Agentenvariante.

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:

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.

Vorhandene APM-Integrationen existing-apm

OpenTelemetry kann nicht zusammen mit einem anderen APM-Agenten in derselben Umgebung ausgeführt werden:

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:

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.

Metriken - JVM-Laufzeitmetriken und HTTP-Servermetriken, die standardmäßige OpenTelemetry-Metriknamen verwenden, und AEM-Metriken unter dem aem.-Präfix (werden bereitgestellt; sie werden automatisch angezeigt, ohne Konfigurationsänderung), einschließlich:

Protokolle - Die Protokolleinträge Ihrer AEM-Anwendung auf WARN und höher, die mit dem Protokollsignal von OpenTelemetry gesendet werden, wenn sie aktiviert sind. Die Möglichkeit, diese Protokollebene anzupassen, befindet sich in der Entwicklung. Protokolleinträge enthalten dieselben Ressourcenattribute wie Traces und Metriken (service.name, deployment.environment) sowie die Trace- und span-Bezeichner der Anfrage, die sie erzeugt hat, sodass sie mit Traces 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:

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

Eine Anleitung zur Verwendung des WKND-Beispielprojekts, von der Speicherung Ihrer Anmeldeinformationen in Cloud Manager bis zur Überprüfung der Telemetrie in Ihrer Beobachtbarkeitsplattform, finden Sie im Tutorial Konfigurieren von OpenTelemetry für Einblicke in AEM-Anwendungen.

Schritt 1: Zugriff anfordern request-access

Senden Sie eine E-Mail 🔗0}aemcs-apm-beta@adobe.com" mit Ihrer Cloud Manager-Programm-ID und den Umgebungs-IDs, die Sie aktivieren möchten. Wenn Sie lieber die Grafana- oder Splunk-Agentenvariante als die Standardvariante verwenden möchten, sagen Sie dies in Ihrer E-Mail (siehe Unterstützte OpenTelemetry-Varianten).

Adobe ermöglicht OpenTelemetry für diese Umgebungen kurz nach der Beantwortung Ihrer Anfrage. Wenn eine Umgebung derzeit die integrierte APM-Integration von Adobe verwendet, sendet diese Integration keine Daten mehr, sobald OpenTelemetry aktiviert ist - siehe "​ APM-Integrationen.

Schritt 2: Fügen Sie Ihre Konfigurationsdatei hinzu add-configuration

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

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

Schritt 3: 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: "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 (über eine Splunk-Verteilung des OpenTelemetry Collector, der als Gateway ausgeführt wird):

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

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

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

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: "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

Schritt 4: Bereitstellen deploy

Nachdem Adobe bestätigt hat, dass OpenTelemetry für Ihre Umgebung aktiviert ist (siehe Schritt 1), führen Sie Ihre Konfigurations-Pipeline aus, um config/otel.yaml bereitzustellen. Die Pipeline validiert Ihre Konfiguration und prüft Ihren Endpunkt und Ihre Anmeldedaten, bevor Sie die Konfiguration anwenden. Daher werden die meisten Fehler direkt im Pipeline-Protokoll gemeldet.

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

Schritt 5: 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 Pipeline einige Minuten, bis die Daten eingegangen sind, und überprüfen Sie dann Ihren APM-Provider auf Folgendes:

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.

Muss ich Zugriff anfordern?

Ja. Senden Sie während der eingeschränkten Verfügbarkeit eine E-Mail an 🔗aemcs-apm-beta@adobe.com) mit Ihren Programm- und Umgebungs-IDs. Adobe ermöglicht OpenTelemetry für diese Umgebungen kurz nach der Beantwortung Ihrer Anfrage. Dies ist noch nicht für HIPAA-Umgebungen verfügbar.

Was passiert mit New Relic, wenn ich OpenTelemetry aktiviere?

Sobald Adobe OpenTelemetry für eine Umgebung auf Anfrage aktiviert hat, werden Daten nicht mehr von dieser Umgebung an New Relic gesendet. Die beiden können nicht gleichzeitig ausgeführt werden.

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

Ja. E-Mail aemcs-apm-beta@adobe.com und Adobe deaktivieren OpenTelemetry für Ihre Umgebungen. Legen Sie dann enabled: false in der config/otel.yaml fest (oder entfernen Sie die Datei), führen Sie die Konfigurations-Pipeline aus und führen Sie eine Full-Stack-Pipeline bis zum Ende aus, um New Relic wiederherzustellen. Dies ist bis Ende November 2026 möglich.

Kann ich OpenTelemetry verwenden, wenn meine Umgebung Dynatrace OneAgent ausführt?

Nicht in derselben Umgebung - Dynatrace OneAgent hat Vorrang. Sie können OneAgent entfernen und stattdessen OpenTelemetry verwenden, einschließlich mit Dynatrace als APM-Provider. Siehe Vorhandene APM-Integrationen.

Was passiert nach November 2026?

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

Verwandte Artikel related-articles