OpenTelemetry 対応

OpenTelemetry とは何で、Datadog はどこで受け取るか

OpenTelemetry は、アプリケーションからトレース / メトリクス / ログを取り出すための SDK と API、そしてそれを運ぶ OTLP というプロトコルを、特定のベンダーに依存しない形で定めた仕組みです。Datadog の公式ドキュメントは 2026 年 9 月時点で、計装の選択肢として「OpenTelemetry の SDK と API を使うベンダー中立の構成」と「OpenTelemetry の API を Datadog の SDK 実装で使う構成」の 2 つを挙げ、使える機能はこの選択と、データを処理して転送する Collector の選択で決まると説明しています (出典: OpenTelemetry in Datadog)。結論を先に言うと、Datadog は OTel のデータを 4 か所で受け取れ、公式が推奨するのは Datadog Agent に同梱された DDOT Collector 経由です。この受け口が無いと、OTel で計装した資産を Datadog で見るには計装を APM の dd-trace 系 SDK に書き換えるしかなく、計装の中立性を諦めることになります。受け口があるおかげで、「計装は標準に寄せ、分析はツールの得意なところを使う」という分業が成立します。ただし全経路で全機能が同じではありません。その差を隠さずに書くのが本稿の目的です。

取り込み経路は 4 つ、公式が推奨するのは DDOT Collector

「Send OpenTelemetry Data to Datadog」のページは 2026 年 9 月時点で、推奨経路として DDOT Collector を置き、その他の選択肢として単体の OpenTelemetry Collector、Agent の OTLP 受信 (OTLP Ingest in the Agent)、直接取り込み (Direct OTLP Ingest) の 3 つを並べています (出典: Send OpenTelemetry Data to Datadog)。

Agent の OTLP 受信は既定で無効で、datadog.yaml か環境変数で有効化します。有効にするとメトリクスとトレースは既定で受け取りますが、OTLP ログは「予期しない課金を避けるため」別のスイッチで明示的に有効化する必要があります (同出典)。また公式は Datadog Agent と別の OpenTelemetry Collector を同じホストで動かさないよう求めているため (出典: Datadog and OpenTelemetry Compatibility)、経路は 1 ホストに 1 つが前提です。

DDOT Collector は従来の Collector + Exporter と何が違うか

DDOT Collector (Datadog Distribution of OpenTelemetry Collector) は、OpenTelemetry Collector の部品のうち Datadog との組み合わせで検証済みのものを選んで同梱したオープンソースの配布版です。そこに Datadog Agent のデータ収集機能と Fleet Automation による遠隔管理が組み合わさっています (2026 年 9 月時点・出典: Datadog Distribution of OpenTelemetry Collector)。標準の Agent パッケージに含まれるので、別のバイナリを配る必要がありません。同梱部品には otlp や prometheus、filelog、hostmetrics の receiver と、datadogexporter を含む exporter 群が並びます (同出典)。従来の「単体 Collector + Datadog Exporter」との差は 3 つです。第一に Datadog 独自の部品があること。Pod やコンテナから出た OTLP データに Kubernetes のタグを自動で付ける Infrastructure Attribute Processor、設定の既知の誤りを補正する Converter、Collector と Agent 両方の診断情報をまとめる DD Flare Extension が列挙されています。第二にサポート水準が部品ごとに明示されていること。Datadog 製は Datadog が保守、既定同梱のコミュニティ部品は Datadog が互換性を確認、既定に無い部品は「案内はするが直接サポートしない」と線が引かれています (出典: Datadog and OpenTelemetry Compatibility)。第三に Agent 側の機能が同じプロセス群で動くため、次節の対応表で「DDOT なら使える」項目が増えることです。設定を遠隔配布する Remote Configuration は 2026 年 9 月時点でプレビュー扱いです。

機能対応の実際 - 使えるもの、使えないもの

「OTel なら全機能が同等」ではありません。公式の互換性ページは 2026 年 9 月時点で、4 つの構成ごとに機能の対応を表にしています (出典: Datadog and OpenTelemetry Compatibility)。段階で整理すると次のとおりです。

Agent の OTLP 受信の解説ページも、OpenTelemetry SDK で計装したデータは App and API Protection、Continuous Profiler、Ingestion Rules では使えないと明記しています (出典: OTLP Ingestion by the Datadog Agent)。実務で効くのは最後の行で、プロファイラでホットスポットを追う、RUM のセッションからバックエンドのトレースへ降りる、といった体験は Datadog SDK 側に残っています。逆にトレースとスパンの可視化やログとの相関という中核は Direct OTLP Ingest でも使えるので、「まず OTel で入れて相関を確かめ、必要になった機能から SDK を切り替える」という段階的な進め方が現実的です。

OTLP で入れたデータは何で数えられるか

OTel 専用の料金があるわけではなく、届いたデータが既存の SKU のどれで数えられるかが問題です。ログについては、Agent の OTLP ログ受信が「予期しない課金を避けるため」既定で無効になっていると明記されており (2026 年 9 月時点・出典: OTLP Ingestion by the Datadog Agent)、有効にすればログ管理の取り込み量として数えられる前提で設計されています。メトリクスについては、公式の定義でカスタムメトリクスは「1,000 を超える Datadog 統合以外から送られたメトリクス」を含むため (出典: Custom Metrics)、アプリが OTel SDK で独自に出したメトリクスはカスタムメトリクスの枠で数えられます。割当は 2026 年 8 月時点でインフラ監視 Pro がホストあたり 100 個、Enterprise が 200 個です (出典: Datadog Pricing)。トレースは APM の課金体系に入り、APM ホスト単価に加えて取り込みスパン量とインデックスするスパン数で決まります。取り込みの割当は 2026 年 8 月時点で APM ホストあたり月 150 GB、インデックス済みスパンの割当はホストあたり月 100 万スパン (15 日保持) で、どちらも全 APM ホストで合算されます (同出典)。料金ページには 2026 年 9 月時点で「OTLP APM Ingest」という区分も掲載されていますが、単価の一次確認ができなかったため本稿では数字を書きません。保持するスパンは取り込み制御で絞ります。注意点として、互換性ページは AWS EKS Fargate と OpenTelemetry Collector の組み合わせを非対応とし、インフラのホスト課金が正しく計算されないと明記しています (出典: 前掲 Compatibility)。料金体系の全体像は料金の読み解きで扱っています。本記事の価格は各時点の実例であり、執筆後の価格改定を反映するものではありません。

ベンダー依存を下げたいなら「計装は OTel、分析は Datadog」の分業は得か

OTel を選ぶ動機の大半は「監視ツールを将来乗り換えられる状態にしたい」です。得るものは計装コードの中立性で、Collector の宛先を変えるだけでバックエンドを差し替えられます。失うものは前節の表の最後の行、Continuous Profiler や RUM 相関といった Datadog SDK にしか無い機能です。判断軸を 3 つに絞ります。

公式ドキュメントが用意している中間解が「OpenTelemetry API + Datadog SDK」の構成です。アプリのコードは OTel の API で書き、その実装として Datadog の SDK を使うため、互換性表では全機能が使える列に入ります (2026 年 9 月時点・出典: Datadog and OpenTelemetry Compatibility)。コードの中立性を保ちつつ Datadog の機能を使う構成なので、「今は Datadog をフルに使うが、コードは縛られたくない」という組織にはこれが最も損の少ない選択です。避けるべき構成も示されていて、同じアプリケーションに Datadog SDK と OpenTelemetry SDK を混在させると未定義の挙動になる (Python など一部の言語は例外として両方を要する) と明記されています (同出典)。分業を決めたら、SDK は 1 種類、経路は 1 ホスト 1 つ、という 2 つの線を守るだけで多くのトラブルを避けられます。

最初の 1 サービスの手順 - Agent の OTLP 受信で試してから DDOT へ

本番の構成を DDOT にするとしても、最初の 1 サービスは Agent の OTLP 受信で試すのが手早く、既に Datadog Agent が動いているホストなら追加のバイナリは不要です。手順は 3 段階です。まず Agent 側で受信を有効にします。環境変数で指定する場合は、コアの Agent とトレース Agent の両プロセスに渡す必要があると公式ドキュメントが注意しています (2026 年 9 月時点・出典: OTLP Ingestion by the Datadog Agent)。

DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINT=0.0.0.0:4318

コンテナ環境では localhost でなく 0.0.0.0 を指定し、対応するポートを公開します。次にアプリ側で送信先を Agent に向けます。OpenTelemetry SDK の標準の環境変数を使います。

OTEL_EXPORTER_OTLP_ENDPOINT=http://<datadog-agent>:4318

最後に Datadog の APM 画面でサービスが現れ、トレースとスパンが期待どおりの service 名で見えることを確かめます。ログも流す場合は DD_LOGS_ENABLED=true と DD_OTLP_CONFIG_LOGS_ENABLED=true の 2 つを追加で有効にします (同出典)。この段階で確認しておくと後が楽なのは、コンテナのタグが付いているかです (公式は OTLP メトリクスに container.id などのリソース属性を付けるよう案内しています)。相関の体験が得られたら、Kubernetes 監視や Live Processes が欲しくなった時点で DDOT Collector に切り替え、プロファイラや RUM 相関が要るサービスだけ Datadog SDK に寄せる、という順で広げると無駄がありません。