OpenTelemetry （Beta） 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の動作と他のサービスの相関関係などが含まれます。これらはすべて、すでに使用しているモニタリングツールから離れることなく実行できます。

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

​* Traces — AEM アプリケーションで処理されるリクエストの分散トレース。
​* 指標 — JVM ランタイム指標（メモリ、ガベージコレクション、スレッド）およびインバウンド HTTP リクエスト率、待ち時間、エラー率などのアプリケーション指標。
​* Logs — OpenTelemetryのログシグナルを使用して送信されたAEM アプリケーションのログ。 ログはオプションで、トレースと指標に依存せずに切り替えることができます。

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

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

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

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

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

デフォルトのアップストリームバリアントは、任意のAPM ベンダーで動作します。 GrafanaとSplunkのバリエーションは、これらのプラットフォームに対してベンダー固有のインストルメントとデフォルトを追加します。

APM ベンダー apm-vendors

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

​* New Relic
​* Grafana Cloud
​* Splunk Observability Cloud
​* Dynatrace
​* Datadog
​* Dash0
​* ハニカム
​* 弾性観察可能性
​* Sumo Logic
​* ServiceNow Cloud Observability

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

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

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

ネットワーク接続 network-connectivity

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

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

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

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

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

​* インバウンド HTTP リクエストのスパン。メソッドとルートで指定します（例：GET /content/...）。
​* リクエストの処理中に生成されたサーブレットとアウトバウンドデータベース（JDBC）のスパン。

大量の内部スケジューラーとヘルスプローブのアクティビティ（Quartz ジョブなど）がフィルタリングされ、トレースがアプリケーションリクエストに集中するように処理されます。 Sling リソース解決、OSGi サービス、JCR アクセスなど、きめ細かいAEM フレームワーク内部スパンは、このリリースでは発行されません。

指標 — JVM ランタイムおよびHTTP サーバー指標。以下を含む標準のOpenTelemetry指標名を使用します。

​* JVM ランタイム：jvm.memory.used、jvm.gc.duration、jvm.thread.count、jvm.cpu.recent_utilization。
​* HTTP サーバー：http.server.request.duration （リクエスト率、待ち時間パーセンタイル、エラー率はこのヒストグラムから派生します）。

Logs – 有効にすると、AEM アプリケーションのログエントリがOpenTelemetryのログシグナルを使用して送信されます。 ログ エントリには、トレースおよび指標（service.name, deployment.environment）と同じリソース属性が含まれているため、それらを関連付けることができます。

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

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

​* service.name — プログラム、環境、サービス、および階層（例：cm-p<program>-e<environment>-aem-publish-prod）を識別します。
​* deployment.environment – 環境タイプ （例：prodまたはstage）。

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

統合の設定 set-up

手順1：統合を有効にする request-access

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

​* この設定が適用される環境タイプ （例：stageとprod）。
​* APM プロバイダーのタイプとOTLP/HTTPS エンドポイント URL （該当する場合は地域を含む）。
​* プロバイダーが使用する認証方法（手順2を参照）。

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

手順2：認証資格情報の設定 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: "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

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

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

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

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

手順3：デプロイ deploy

統合は、次の​ デプロイメント ​に対して有効になります。つまり、Cloud Managerのデプロイメントパイプラインが次回に実行されるとき（フルスタックデプロイメントなど）。 config/otel.yaml ファイルを追加して資格情報を設定してから環境がデプロイされていない場合は、デプロイメントを実行してアクティブ化します。

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

手順4：統合の検証 verify

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

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

​* Traces — AEM サービスの新しいスパン。 例えば、オーサー層またはパブリッシュ層のservice.nameを検索するか、インバウンド HTTP リクエスト スパンを検索します。
​* 指標 — サービスの受信jvm.*およびhttp.server.*指標。
​* ログ （有効な場合） — AEM サービスの受信ログエントリ。

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

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

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

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

FAQ faq

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

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

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

設定パイプラインを実行すると、New RelicへのデータがAEM as a Cloud Serviceから送信されなくなります。

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

はい。 設定パイプラインを使用してOpenTelemetryを無効にし、フルスタックパイプラインを実行して完了します。 これは2026年11月末まで可能です。

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

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

関連記事 related-articles

​* ログ転送
​* 高度なネットワークの設定
​* Cloud Manager の環境変数