Datadog OpenTelemetry連携の4方式｜OTLP送信とDDOTの選び分け

OpenTelemetryで計装したアプリケーションからDatadogへテレメトリを送る経路は、2026年8月時点の公式ドキュメントで4通りに整理されています。DDOT Collector、コミュニティ版のOpenTelemetry Collector、Datadog AgentのOTLP受信、そしてインテークエンドポイントへの直接送信です。この記事では4方式の要件と上限値、Datadog独自機能のうちOTel経路で使えなくなるもの、リソース属性とタグの対応、そして計装をOTelに寄せたままDatadogをバックエンドに選ぶ条件と見送る場面までを、実装する側の判断材料として整理します。

まとめ：4方式の選び分けと連携前に確認する機能差

結論から示します。Kubernetes上でDatadogの周辺機能まで使うならDDOT Collector、テールベースサンプリングなど中立的な加工を挟みたいならコミュニティ版Collector、Kubernetes以外のホストで部品を増やしたくないならAgentのOTLP受信、サーバーレスなど常駐プロセスを置けない環境だけ直接インテーク、という順で候補を絞ると迷いません。

方式選択より先に確認すべきなのは機能差のほうです。Continuous ProfilerやApp and API Protection、Data ObservabilityのJobs MonitoringはOTel計装のままでは使えず、コミュニティ版Collectorに至ってはDatabase MonitoringやLive Processes、Universal Service Monitoringといったホスト由来の機能も外れます。契約前の提案で「Datadogの全機能が使える」と説明すると、実装フェーズで前提が崩れます。先に要件表と突き合わせてください。

DatadogがOpenTelemetryを受け取る4つの経路と役割分担

4方式は優劣ではなく、どこで正規化と付帯情報の付与を行うかの違いです。テレメトリの規格そのものについてはOpenTelemetry（OTel）の3つのシグナルとOTLP・Collectorの役割を先に押さえておくと、以降の設定項目が何を指しているか読み解けます。

DDOT Collector経由でDatadog固有機能を残す標準構成

DDOTはDatadog Distribution of OTel Collectorの略で、Datadog Agentに同梱される形で動くCollectorディストリビューションです。公式ドキュメントが推奨として最初に挙げているのはこの構成で、Fleet Automation、Live Container Monitoring、Kubernetes Explorer、1,000を超えるインテグレーションといったAgent側の資産を維持したまま、OTLPで届いたデータを扱えます。

計装側はOTelのSDKのまま、収集基盤だけDatadogの管理下に置く形です。ベンダー中立性を100%取りにいく構成ではありませんが、計装コードにDatadog固有のAPIが入らないため、将来バックエンドを差し替える際に手を入れる範囲はCollector設定に閉じます。

コミュニティ版OTel Collectorで中立性を保つ構成の条件

OpenTelemetry本家のCollector（contribディストリビューションなど）にDatadog Exporterを設定して送る構成です。公式は「完全にベンダー中立な構成を望む新規・既存のOTelユーザー」向けと位置づけており、テールベースサンプリングやデータ変換といった加工をCollector側で完結させたい場合はこちらになります。

代償はホスト由来の機能です。Database Monitoring、Cloud Network Monitoring、Live Container Monitoring、Live Processes、Universal Service Monitoringは、コミュニティ版Collectorでは非対応と明記されています。エージェントレスで統一したい要件と、これらの機能要求は両立しません。

Datadog AgentのOTLP受信で部品数を増やさない選択

すでにDatadog Agentを入れているホストなら、AgentにOTLPの受信口を開けるのが最短です。公式はこの方式を「Kubernetes Linux以外のプラットフォームを使う場合、またはCollectorのパイプライン管理を避けて最小構成にしたい場合」に向くとしています。Datadog本体の機能範囲についてはDatadogの機能構成と導入時に見る観点を参照してください。

Collectorのプロセスを別途管理しないぶん、可観測性パイプラインとしての加工能力は限定されます。サンプリング方針をアプリ側かDatadog側のどちらかに寄せられる案件向きです。

直接OTLPインテークで中継を持たない最小構成の適用範囲と判断条件

Datadogのインテークエンドポイントへアプリケーションから直接OTLPを送る方式です。公式は本番ワークロードにはAgentかCollectorの利用を推奨し、直接送信は「サーバーレス、マネージドプラットフォーム、リソース制約のある環境など、それらを配置できない場合に限る」と用途を絞っています。

組織によってはCustomer Success Manager経由での有効化が必要と記載されており、設計段階で使える前提にするのは危険です。送信可否を先に確認してから構成を確定させてください。

Datadog Agent側のOTLP受信設定とポート開放の実装手順

Agent方式は設定項目が少ない反面、既定値のままでは1バイトも受け取りません。最初に詰まるのはここです。

既定で無効のOTLP受信を有効化する環境変数と待受アドレスの設定手順

AgentのOTLP取り込みは既定でオフです。datadog.yamlでの設定か環境変数で明示的に有効化します。gRPCで受けるならDD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_ENDPOINTに0.0.0.0:4317を、HTTPならDD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINTに0.0.0.0:4318を指定し、コンテナ側でも同じポートを公開します。

ポート番号はOTLPの標準どおりです。Kubernetesでサイドカーやデーモンセットとして動かす場合、待受アドレスをループバックのままにするとPod外から到達できません。設定値の見落としで「Agentは動いているのにデータが来ない」となる典型例がこれです。

アプリ側のエクスポート先指定とgRPC・HTTPの選び分け基準

送信側はOTelの標準環境変数OTEL_EXPORTER_OTLP_ENDPOINTにAgentの待受先を渡すだけで、Datadog固有のコードは不要です。gRPCとHTTPの選択は、経路上のプロキシやロードバランサがHTTP/2をそのまま通せるかで決めると失敗しません。マネージドなL7ロードバランサを挟む構成ではHTTPのほうが素直に通ります。

• Pod内で直接Agentへ送る：gRPCで問題ない
• L7経由やサービスメッシュ越し：HTTPを既定にする
• 直接インテークへ送る：後述のとおりgRPCは選べない

迷ったらHTTPで疎通を取り、スループット要件が見えてからgRPCへ寄せる順番が安全です。

AgentとCollectorを同一ホストに同居させない構成上の制約

公式ドキュメントは、Datadog Agentと独立したOpenTelemetry Collectorを同じホストで動かすことを避けるよう明記しています。メトリクスの二重計上やホストタグの競合が起きるためで、移行期に「まずCollectorを入れて、Agentは残したまま様子を見る」という進め方は問題を起こします。

移行するならホスト単位で切り替えるか、DDOTのようにAgentへ統合された形を採るかの二択です。監視基盤の切り替えは既存アラートの移設とセットで計画してください。設定をコード管理しているなら、TerraformでDatadogのモニターを管理する手順を併読すると移設の見通しが立ちます。

DDOT Collectorの要件とコミュニティ版Collectorとの機能差

推奨構成と書かれているDDOTには、動かせる環境の条件があります。要件を満たさない案件では最初から選択肢から外れます。

Kubernetes v1.29系以上とAgentイメージタグの前提条件

2026年8月時点のインストールガイドでは、DaemonSet構成の前提としてLinux上で動くKubernetesクラスタ（v1.29系以上）とHelm v3系以上が挙げられています。ノードエージェントのイメージタグを上書きする場合は7.67系以上を指定しないとOTelコンテナがスケジュールされず、Datadog Operatorはv1.22.0以降でDDOTコンテナに専用イメージを使う構成へ変わっています。

裏を返すと、Kubernetes以外のホストやWindowsノード中心の環境ではDDOTを前提にできません。オンプレミスの仮想マシン主体の構成なら、AgentのOTLP受信方式へ倒すのが現実的です。

同梱コンポーネントの範囲と独自部品を足す場合の再ビルド判断条件

DDOTには既定でレシーバ（OTLP、Prometheus、Jaeger、Kubernetes、Dockerの統計情報など）、プロセッサ（batch、フィルタ、サンプリング、Kubernetes属性付与）、エクスポータ（Datadog、OTLP、debug）、コネクタや拡張が同梱されます。日常的な構成なら追加なしで組めます。

同梱外のコンポーネントが必要になった場合は、カスタムコンポーネントの手順に従って作り直す必要があります。「Collectorの設定ファイルを書き換えるだけ」では済まないため、特殊なレシーバやエクスポータを前提にした設計は、着手前に同梱一覧と突き合わせておくべきです。

コミュニティ版で落ちるDatadog固有機能の具体的な内訳と確認方法

方式によって使える機能が変わる点は、契約範囲の説明で最も誤解を招きます。2026年8月時点の互換性一覧から、影響の大きい項目を抜き出します。

分散トレーシング、メトリクス、ログの相関、Cloud SIEM、ランタイムメトリクス、Kubernetes・インフラ監視は、いずれの構成でも広く対応しています。落ちるのは主にプロファイリングとホスト内部の可視化です。

直接OTLPインテークのペイロード上限と本番運用から外す条件

直接送信は構成が最も軽い一方、明示された上限と制約があります。数値で押さえておくと採否を即断できます。

シグナル別のペイロード上限と413が返る境界の見積もりと対処方針

公式が示す最大ペイロードサイズは、メトリクスが512KiB（圧縮後）、ログが5.1MiB（非圧縮）、トレースが15MiB（非圧縮）です。これを超えたリクエストにはHTTP 413が返ります。トレース側はエンドポイントがHTTPのprotobuf形式とJSON形式に対応し、gRPCは非対応と明記されています。

バッチサイズを大きく取るSDK設定のまま直接送ると、断続的に413で落ちる形で表面化します。送信間隔を短くしてバッチを小さく保つ設計にしてください。

ホスト一覧に載らない・トレースメトリクスが標本になる制約と運用判断

このエンドポイントへ送ったホストメタデータは、Infrastructure Host Listに反映されません。インフラ一覧でホストが見えることを前提にした運用設計とは噛み合わない、という意味です。トレース側のリクエスト数やレイテンシといったトレースメトリクスも、Datadogに到達したスパンから計算されるため、OTel側でサンプリングを効かせているとその影響をそのまま受けます。

ヘッダはdd-api-keyでAPIキーを渡し、トレースメトリクスの計算を有効にするならcompute_statsを、スパンのマッピング指定が要る場合はdd-otel-span-mappingを添えます。正常時の応答はHTTP 202です。

OTelリソース属性とDatadogタグの対応と設定重複の回避

連携で最も多い相談が「サービス名や環境が想定どおりに出ない」です。原因はほぼ属性の対応関係と設定の二重指定に絞られます。

service.nameとdeployment.environment.nameタグ対応

OTelのセマンティック規約とDatadogの主要タグは対応関係が定義済みです。service.nameがDD_SERVICE、deployment.environment.nameがDD_ENV、service.versionがDD_VERSIONに対応します。指定はOTEL_SERVICE_NAMEかOTEL_RESOURCE_ATTRIBUTESのキーとして渡します。

環境名についてはdeployment.environmentという旧来のキーでも受け付けられますが、新規に組むなら現行の名称に揃えるほうが後々の混乱を避けられます。この3つが揃っていないと、APMのサービス一覧やデプロイ追跡が期待どおりに機能しません。

DD_とOTEL_の優先順位とタグ重複を生む設定の見分け方と解消手順

同じ概念に対してDatadog系の環境変数とOTel系の環境変数を両方設定すると、タグが重複した状態になります。公式は明確に「同一概念に両方を設定しない」と注意しています。適用の優先順位は次のとおりです。

1. Datadog固有の環境変数（DD_で始まるもの）
2. Datadogのタグ設定（DD_TAGS）
3. OTelの環境変数（OTEL_で始まるもの）
4. OTelのリソース属性

ここを理解していないと、Helmのvaluesで入れたDD_系と、アプリのDeploymentマニフェストに書いたOTEL_系が食い違い、片方だけが効く状態になります。設定の出どころを1箇所に固定するのが対処です。

OTel計装のままDatadogを採用する条件と見送るべき場面

ここは判断を言い切ります。OTel計装＋Datadogという組み合わせは、条件が合えば強力ですが、合わない案件では素直にDatadog純正の計装を選ぶか、別のバックエンドを見るべきです。

バックエンドの差し替え可能性を残したい場合の具体的な採用条件

採用してよいのは、次の2つを同時に満たすときです。第一に、監視対象がアプリケーションのトレース・メトリクス・ログに収まり、プロセス内部のプロファイリングやデータベース内部の可視化を当面の要件に含めないこと。第二に、収集基盤（Collector）を運用する担当が決まっていること。

この条件下では、計装コードがOTelの規約に閉じるため、将来Datadogから他のバックエンドへ切り替えても、アプリケーション側の改修は最小で済みます。中立なバックエンドを併走候補に置くなら、OpenTelemetryを取り込んだJaeger v2の構成と比較しておくと、乗り換え先の現実味を評価できます。Grafanaスタックを候補に入れる場合は、OTLPをLoki・Mimir・Tempoへ振り分ける構成も併せて確認してください。

プロファイラや保護機能が要件にある案件で採用を見送る判断基準

Continuous Profilerでの継続的なプロファイリング、App and API Protectionによるアプリケーション保護、Data ObservabilityのJobs Monitoringが要件に入っているなら、OTel計装一本での構成は見送りです。これらはDatadog SDKでの計装（App and API ProtectionはDDOTとの併用）が前提になっており、機能を諦めるか計装を戻すかの二択になります。

「あとから足せる」と考えないでください。計装のやり直しは、対象サービス数ぶんのリリース作業になります。要件定義の段階で機能一覧と方式を突き合わせるのが唯一の回避策です。

小規模構成でCollectorを立てる運用コストの損益分岐と判断基準

サービス数が2〜3、ホストも数台という規模でコミュニティ版Collectorを別途立てるのは過剰です。Collector自体の可用性・バージョン追従・設定管理という運用対象が増え、得られる中立性に見合いません。この規模ならAgentのOTLP受信で受けるか、DDOTに寄せて管理点を1つに畳むべきです。

損益分岐は、テールベースサンプリングや属性の加工をパイプライン側で行いたい要件が出てきたあたりにあります。監視基盤の設計と、その後の運用体制まで含めて相談したい場合は、システムの保守運用・内製化支援で構成レビューから引き受けています。

よくある質問

DatadogとOpenTelemetryの連携について、実装前に確認されることの多い5問に答えます。

OpenTelemetryで計装すればDatadogの機能はすべて使えますか？

使えません。分散トレーシング、メトリクス、ログの相関、Cloud SIEM、Kubernetes・インフラ監視は広く対応していますが、Continuous ProfilerやApp and API Protection、Data ObservabilityのJobs MonitoringはOTel計装のままでは対象外です。コミュニティ版Collectorを使う場合はさらにDatabase MonitoringやLive Processes、Universal Service Monitoringも外れます。要件表と互換性一覧を突き合わせてから方式を決めてください。

Datadog AgentとOpenTelemetry Collectorは同居させてよいですか？

公式ドキュメントは、同一ホストでDatadog Agentと独立したOpenTelemetry Collectorを動かすことを避けるよう記載しています。メトリクスの二重計上やホストタグの競合が起きるためです。移行するならホスト単位で切り替えるか、Agentに統合されたDDOT Collectorを使う形にします。並走での段階移行を計画している場合は、ホスト単位のカナリアに設計を変えるのが安全です。

直接OTLPインテークへgRPCで送ることはできますか？

トレースのインテークエンドポイントはHTTPのprotobuf形式とJSON形式に対応し、gRPCは非対応と明記されています。gRPCで送りたい場合は、Datadog AgentのOTLP受信（ポート4317）かCollectorを経由してください。なお直接インテークは本番ワークロードでは推奨されておらず、サーバーレスなど常駐部品を置けない環境向けの選択肢という位置づけです。

DDOT CollectorはKubernetes以外でも動きますか？

2026年8月時点のインストールガイドはLinux上のKubernetes（v1.29系以上）のDaemonSet構成とゲートウェイ構成を対象にしており、Kubernetes以外のホストへの導入手順は示されていません。仮想マシン中心の環境やWindowsノードが主体の構成では、Datadog AgentのOTLP受信を有効化する方式を選ぶことになります。要件の切り分けはこの点から入ると早いです。

サービス名や環境名がDatadog側で想定どおりに出ないのはなぜですか？

リソース属性とDatadogタグの対応、または設定の二重指定が原因である場合がほとんどです。service.nameがDD_SERVICE、deployment.environment.nameがDD_ENV、service.versionがDD_VERSIONに対応します。DD_系とOTEL_系を同じ概念に両方設定するとタグが重複するため、優先順位（DD_系、DD_TAGS、OTEL_系、リソース属性の順）を踏まえ、設定の出どころを1箇所に固定してください。

関連記事

• OpenTelemetry（OTel）とは：3つのシグナル・OTLP・Collectorという、この記事の前提になる規格側の解説です。
• Datadogとは何か：バックエンド側の機能構成と導入背景を、製品概要の粒度で確認できます。
• Cloud Traceとは：Google Cloud側でOTelを受ける場合の構成と料金で、Datadogとの比較材料になります。
• Application Insightsとは：Azure側のOTel受け口と料金体系で、マルチクラウド前提の選定時に併読できます。
• Bits AI SREの基本概要：連携後にDatadog側で使える運用自動化の位置づけを把握できます。