AEM用OpenTelemetry opentelemetry-apm

Adobeは、AEM as a Cloud Serviceに組み込まれたApplication Performance Monitoring （APM）統合を、OpenTelemetryに置き換えます。これは、すべての主要なモニタリングプラットフォームでサポートされている、オープンで業界標準のオブザーバビリティのアプローチです。

現在、AEM as a Cloud Serviceには、Adobe全体で管理されるAPM統合が組み込まれています。 統合が置き換えられたら、独自のAPM エンドポイント​を使用する必要があります。これは、OpenTelemetry データを受け入れるベンダープラットフォーム、またはセルフホスト（オンプレミス）のOpenTelemetry互換バックエンドです。

この変更の利点 benefits

概要 overview

AEM as a Cloud Serviceは、可観測性に対するオープンな業界標準アプローチであるOpenTelemetryを使用してアプリケーションからテレメトリを生成し、選択したAPM プロバイダーに転送できます。 これにより、AEMアプリケーションを、他のシステムと並行して、チームが既に使用しているツールで監視することができます。

この統合を使用する一般的な理由には、遅いリクエストや失敗したリクエストの調査、JVMの健全性とリソースの使用状況の経時的な追跡、AEM階層のダッシュボードとアラートの構築、インシデント時のAEMの動作と他のサービスの相関関係などが含まれます。これらはすべて、すでに使用しているモニタリングツールから離れることなく実行できます。

次のテレメトリはスコープ内にあります。

​ ログ転送は、既存の個別のメカニズムを通じて引き続きサポートされており、この統合の影響を受けません。

AEMからAPM プラットフォームへのテレメトリの流れ、制御する内容、プラットフォームの選び方など、テレメトリの仕組みについて詳しくは、チュートリアル「OpenTelemetryを使用したオブザーバビリティ ​」を参照してください。

サポートされているOpenTelemetry バージョン supported-versions

OpenTelemetry エージェントは、Cloud Service ランタイムの一部として実行されます。 Adobeが提供し、最新の状態に保たれるため、自分でインストール、管理、アップグレードする必要はありません。 具体的なパッチバージョンは、Adobeがエージェントを更新すると変更される場合があります。

サポートされているOpenTelemetry バリアント supported-variants

AEM アプリケーションは、上記のバージョンに基づいて、次のOpenTelemetry エージェントバリアント（ディストリビューション）のいずれかを使用してインストルメントできます。 詳しくは、各プロジェクトのドキュメントを参照してください。

デフォルトのアップストリームバリアントは、任意のAPM ベンダーで動作します。 GrafanaとSplunkのバリエーションは、これらのプラットフォームに対してベンダー固有のインストルメントとデフォルトを追加します。 Adobeは、選択したエージェントバリアントをデプロイメント時にAEM コンテナにインストールします。 可用性が制限されている間、アップストリームのバリアントはデフォルトで使用されます。GrafanaまたはSplunk バリアントを使用するには、​ アクセスをリクエスト ​するときにリクエストしてください。 config/otel.yaml ファイルは、テレメトリが送信される場所を設定します。エージェントのバリアントを選択するフィールドはありません。

APM ベンダー apm-vendors

OTLP/HTTPS​経由でOpenTelemetry データを受け入れる任意のApplication Performance Monitoring ベンダーにテレメトリを送信できます。 これは、選択したOpenTelemetry バリアントとは独立しています。 OTLP/HTTPSに対応しているベンダーは、次のとおりです。

このリストは網羅的なものではありません。OTLP/HTTPS エンドポイントを公開するあらゆるバックエンドを使用できます。

サポート対象の環境 supported-environments

この統合は、Cloud Manager 実稼動、ステージ、開発​環境で有効にできます。 各環境は個別に有効になっています。手順1を参照してください。 高速開発環境（RDE）はサポートされていません。

既存のAPM統合 existing-apm

OpenTelemetryは、同じ環境で別のAPM エージェントと一緒に実行することはできません。

ネットワーク接続 network-connectivity

APM プロバイダーのエンドポイントには、AEM as a Cloud Service環境からHTTPS経由でアクセスできる必要があります。

APM エンドポイントがプライベートである場合、または安定した既知のIP アドレスから離脱するためにアウトバウンドトラフィックが必要な場合、この統合では、専用エグレスを使用した​ アドバンストネットワーク ​をサポートします。 有効にする方法については、​ アドバンスドネットワーク ​を参照してください。

送信されるデータ what-data-is-sent

AEM アプリケーション によって生成されたトレース、指標、および（有効な場合）ログのみが、APM プロバイダーに送信されます。​次に、期待できるデータの例を示します。

Traces — アプリケーションが処理するリクエストの範囲です。次を含みます。

大量の内部スケジューラーとヘルスプローブのアクティビティ（Quartz ジョブなど）がフィルタリングされ、トレースがアプリケーションリクエストに集中するように処理されます。

指標 — JVM ランタイムおよびHTTP サーバー指標で、標準のOpenTelemetry指標の名前を使用し、aem.接頭辞の下のAEM指標を使用します（ロールアウト中です。これらは自動的に表示され、設定は変更されません）。次の項目が含まれます。

Logs – 有効になっている場合、OpenTelemetryのログ信号を使用して送信される、WARN レベル以上のAEM アプリケーションのログエントリ。 このログレベルの調整機能は開発中です。 ログ エントリには、トレースと指標（service.name, deployment.environment）と同じリソース属性が含まれ、ログ エントリを生成したリクエストのトレース識別子とスパン識別子はトレースと関連付けることができます。

この方法で送信されたログは、​ ログ転送とは独立しています。同じ宛先に対して両方を有効にすると重複が発生する理由については、概要を参照してください。

テレメトリの識別方法 – 各トレースと指標には、次のようなリソース属性が含まれます。

Cloud Service ランタイムと、アプリケーションをホストするプラットフォーム（内部ホスト名、アドレス、コンテナ ID、オペレーティングシステムまたはプロセスの詳細など）に関する情報は、データが外部に出る前に削除されます。

統合の設定 set-up

WKND サンプルプロジェクトを使用するガイド付きチュートリアルでは、Cloud Managerに資格情報を保存することから、識別可能性プラットフォームでテレメトリを検証することまで、チュートリアル AEM アプリケーションのインサイトを得るためのOpenTelemetryの設定を参照してください。

手順1：アクセスのリクエスト request-access

Cloud Manager プログラム IDと、有効にする環境IDを記載したメール aemcs-apm-beta@adobe.comを送信します。 デフォルトではなくGrafanaまたはSplunk エージェントのバリアントを使用する場合は、電子メールでそう言います（​ サポートされているOpenTelemetry バリアント ​を参照）。

Adobeでは、リクエストに応答した直後にこれらの環境に対してOpenTelemetryが有効になります。 現在、Adobeの組み込みAPM統合を使用している場合、OpenTelemetryが有効になると、その統合がデータの送信を停止します。既存のAPM統合を参照してください。

手順2：設定ファイルを追加する add-configuration

Cloud Manager Config Pipeline リポジトリにconfig/otel.yaml ファイルを追加します。 少なくとも、次を指定します。

New Relic、Dynatrace、Grafana Cloud、Splunk、Datadog、Dash0、および汎用またはセルフホスト型エンドポイントの例など、正確なファイル形式については、以下の設定の例を参照してください。

手順3：認証資格情報の設定 configure-credential

Cloud ManagerでOTEL_CUSTOMER_AUTHという名前の​ シークレット環境変数を宣言することで、APM プロバイダーが必要とする資格情報を指定します。 作成者、公開、プレビューの各層で資格情報を使用できるように、Service Applied​を​ All ​に設定します。

環境変数を追加または更新するには、​ デプロイメントマネージャーの役割のメンバーである必要があります。 完全な手順については、Cloud Managerの環境変数を参照してください。

プロバイダーの認証方法に応じて値を設定します。

プロバイダー固有の設定 provider-specific

次の表に、一部の一般的なプロバイダーのエンドポイントと認証の概要を示します。 プロバイダーのドキュメントで必ず現在の値を確認してください。 カスタムヘッダー（New RelicやDatadogなど）を使用するプロバイダーの場合は、OTEL_CUSTOMER_AUTHを生のキー値のみに設定し、設定ファイルのauthHeaderNameを正しいヘッダー名に設定します（設定の例を参照）。

設定例 example-configuration

次のようなファイルを、​ プロバイダー固有の設定のプロバイダーに基づいて、Config パイプラインリポジトリの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 （ゲートウェイとして実行されているOpenTelemetry CollectorのSplunk ディストリビューションを通じて）:

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

汎用エンドポイントまたはセルフホスト エンドポイント （オンプレミス OpenTelemetry コレクターなど）:

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

高度なネットワーク （専用エグレス） — プライベート エンドポイント、またはトラフィックが既知の安定したIP アドレスから離れる必要があるエンドポイントの場合（​ ネットワーク接続を参照）:

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

手順4：デプロイ deploy

AdobeでOpenTelemetryが有効になっていることが確認されたら（手順1を参照）、Config パイプラインを実行してconfig/otel.yamlをデプロイします。 パイプラインでは、設定を検証し、設定を適用する前にエンドポイントと資格情報を確認するので、ほとんどの間違いはパイプラインログで直接報告されます。

パイプラインが完了すると、AEM アプリケーションのトレース、指標、および（有効な場合）ログがAPM プロバイダーに表示され始めます。 確認するには、手順5を使用します。

手順5：統合の確認 verify

テレメトリは独自のAPM プロバイダーに送信されるので、プロバイダーのツールからの統合を確認します。Adobeはこのデータを表示しません。

パイプラインが完了したら、データが到着するまで数分待ってから、APM プロバイダーで次の点を確認します。

このデータが表示された場合、統合は機能しています。

トラブルシューティング troubleshooting

テレメトリがAPM プロバイダーに表示されない場合は、次の点を確認してください。

これらのチェックを行ってもテレメトリが表示されない場合は、aemcs-apm-beta@adobe.comにプログラムと環境の詳細を問い合わせてください。

FAQ faq

なぜこの変更が行われるのですか？

AEM as a Cloud Serviceのお客様は、コンテキスト内のトレース、スパン、ログだけでなく、追加の指標と運用データを求めています。 OpenTelemetryは、これらの機能をすべてサポートする業界標準であり、広くサポートされている形式（OTLP）で出力します。

アクセスをリクエストする必要がありますか？

はい。 利用制限がある場合は、プログラム IDと環境IDをaemcs-apm-beta@adobe.comに電子メールで送信します。 Adobeでは、リクエストに応答した直後にこれらの環境に対してOpenTelemetryが有効になります。 これは、HIPAA スコープの環境ではまだ使用できません。

OpenTelemetryを有効にすると、New Relicはどうなりますか？

Adobeでリクエスト時に環境のOpenTelemetryを有効にすると、その環境からNew Relicにデータが送信されなくなります。 2人は同時に走れない。

New RelicからOpenTelemetryに移行する場合、元に戻すことはできますか？

はい。 お使いの環境では、メール aemcs-apm-beta@adobe.comおよびAdobeがOpenTelemetryを無効にします。 次に、config/otel.yaml ファイルにenabled: falseを設定し（またはファイルを削除）、Config パイプラインを実行し、フルスタックパイプラインを実行して完了し、New Relicを復元します。 これは2026年11月末まで可能です。

環境でDynatrace OneAgentを実行している場合、OpenTelemetryを使用できますか？

同じ環境ではなく、Dynatrace OneAgentが優先されます。 OneAgentを削除し、代わりにOpenTelemetryを使用できます。これには、DynatraceをAPM プロバイダーとして使用することも含まれます。 既存のAPM統合を参照してください。

2026年11月の後はどうなりますか？

Adobeは、組み込みのAPM ソリューションから、永続的なオブザーバビリティソリューションとしてOpenTelemetryに移行します。

関連記事 related-articles