Datadog OpenTelemetry連携の4方式｜OTLP送信・DDOT・dd-traceとOTel SDKの選び分け

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

まとめ：DatadogとOpenTelemetry連携は4方式の選び分けと機能差の確認で決まる

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

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

計装ライブラリの選択も同時に決めます。DatadogのOpenTelemetry互換性ページが推奨として最初に掲げるのは「Datadog SDK＋DDOT」で、アプリのコードはOTel APIで書き、実装部分だけをdd-traceに任せる形です。Datadog固有機能を全部使いたいならこの組み合わせ、将来のバックエンド差し替えを優先するならOTel SDKで計装する、という線引きになります。

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

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

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ディストリビューションなど）から送る構成です。公式は「自分で管理するCollector向けの推奨構成」と位置づけており、テールベースサンプリングやデータ変換といった加工をCollector側で完結させたい場合はこちらになります。2026年9月時点の設定ガイドでは、送信部品がDatadog ExporterからOTLP HTTP exporterへ切り替わっており、設定の中身は後の章で具体例とともに示します。

代償はホスト由来の機能です。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の機能構成と導入時に見る観点を、Agent自体の入れ方はDatadog Agentをホスト・Docker・DaemonSetへ導入する手順を参照してください。

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

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

Datadogのインテークエンドポイントへアプリケーションから直接OTLPを送る方式です。OTLPインテークのガイドは本番ワークロードにはAgentかCollectorの利用を推奨し、直接送信はサーバーレス関数やリソース制約の厳しい環境など、それらを配置できない場合に限ると用途を絞っています。Cloudflare、Vercel、Heroku、Netlifyといったマネージドプラットフォーム向けの個別手順も用意されています。

以前のドキュメントでは組織によってCustomer Success Manager経由の有効化が必要と書かれていた時期もあり、設計段階で使える前提にするのは危険です。検証用のAPIキーで実際に202が返ることを確かめてから構成を確定させてください。

dd-traceとOTel SDKのどちらで計装するかを決める選択基準

「Datadogに送るならdd-traceで計装すべきか、OTel SDKで計装すべきか」は、方式選択と並んで最初に聞かれる論点です。答えは、使いたいDatadog機能とロックインをどこまで許容するかで決まります。

公式が示す4つのセットアップ型とAPI・SDK・収集部品の組み合わせ

Datadogの互換性ページは、連携構成をAPI・SDK・収集部品の組み合わせで4型に分けています。コードが呼ぶAPIと、そのAPIを実装するSDKは別物として選べます。

Datadog SDKだけが対応する機能は、App and API Protection、Continuous Profiler、Data Jobs Monitoring、Data Streams Monitoring、RUMとの完全な相関、ソースコード連携です。これらのうち1つでも要件にあるなら、計装ライブラリはdd-trace一択と考えてください。

OTel APIでコードを書きdd-traceに実装させてロックインを抑える手順

dd-traceにはOTel APIを受け付けるモードがあります。Datadog SDKのOTel API対応ページによると、トレースはDD_TRACE_OTEL_ENABLED、メトリクスはDD_METRICS_OTEL_ENABLED、ログはDD_LOGS_OTEL_ENABLEDをtrueにすると、アプリが呼ぶOTel APIの実体をdd-traceが引き受けます。Pythonでメトリクスまで扱う場合の最小手順は次のとおりです。

# Datadog SDK（dd-trace-py）とOTelのSDK・エクスポータを入れる
pip install ddtrace
pip install opentelemetry-sdk opentelemetry-exporter-otlp

# OTel APIの呼び出しをdd-traceに実装させる
export DD_TRACE_OTEL_ENABLED=true
export DD_METRICS_OTEL_ENABLED=true

# dd-traceの自動計装を有効にして起動する
ddtrace-run python my_app.py

アプリ側のスパン作成コードはfrom opentelemetry import traceで取得したトレーサを使う、OTel標準の書き方のままです。こうしておくと、将来OTel SDKへ戻すときに書き換えるのは依存パッケージと起動コマンドだけで済み、業務コードには手が入りません。dd-trace単体の自動計装やサンプリング設計の詳細はDatadog APMをdd-traceの自動計装で導入する手順で扱っています。

同じアプリにDatadog SDKとOTel SDKを混在させない理由と例外

互換性ページのベストプラクティスは、同一アプリケーションでDatadog SDKとOpenTelemetry SDKの両方を使うと動作が未定義になるとして、混在を避けるよう求めています。例外として挙がっているのはPythonなど一部の言語で、上のコード例のようにDatadog SDKとOTel SDKの両方を入れる手順が公式に定められているものです。

「既存のdd-trace計装を残したまま、新規サービスだけOTel SDKで書く」はサービス単位なら成立しますが、1つのプロセスの中で両者を並走させる移行計画は避けてください。移行はサービス単位で切り替え、トレースコンテキストの伝播ヘッダ（W3C Trace Contextなど）を両側で揃えておくのが安全な進め方です。

言語別のOTel API対応状況と必要なDatadog SDKの版を確認する

2026年9月時点の互換性表では、.NET、Python、Node.js、Java、Go、Ruby、PHPの7言語でトレース・メトリクス・ログのOTel APIに対応しています。ただしRubyのメトリクスAPIはAlpha扱いで、OTelのRuby向けメトリクスSDK自体もアルファ実装と注記されています。

メトリクスとログはOTLPで送られるため、受け側のAgentかCollectorが4317（gRPC）か4318（HTTP）で待ち受けている必要があります。一方、Datadog SDKのランタイムメトリクスは従来どおりDogStatsD（UDP 8125）経由で、OTLPには乗りません。ポート開放の設計で見落としやすい差です。

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を指定し、コンテナ側でも同じポートを公開します。datadog.yamlで書く場合は次の形です。

otlp_config:
  receiver:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  logs:
    enabled: true   # ログのOTLP取り込みは既定で無効
logs_enabled: true  # Agent自体のログ収集も有効にする

受信を有効にするとトレースとメトリクスの取り込みは既定でオンになりますが、ログは想定外の課金を避けるため既定で無効です。ログまで送るならlogs_enabledとotlp_config.logs.enabledの両方を明示します。対応版はトレースとメトリクスがAgent 7.32.0系以上、ログが7.48.0系以上です（2026年9月時点のガイド記載）。

ポート番号は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は残したまま様子を見る」という進め方は問題を起こします。同じフリートの別ホストでAgentとCollectorが混在するのは許容範囲です。

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

コミュニティ版CollectorからDatadogへOTLPで送る設定例と注意点

本家Collectorから送る構成は、2026年9月時点で設定の作法が変わっています。以前の解説記事に多い「Datadog ExporterとDatadog Connectorを並べる」形ではなく、Collector設定ガイドはOTLP HTTP exporterでDatadogのOTLPインテークへ送る構成を推奨しています。

Contrib v0.154.0系で検証済みのOTLP HTTP exporter設定例

ガイドの構成はOpenTelemetry Collector Contrib v0.154.0で検証済みと記載されています。ホスト（ベアメタルや仮想マシン）で動かす設定から、骨格だけを抜き出すと次のようになります。span_metricsのdimensionsは紙幅の都合で一部だけ載せているため、実運用ではガイドの全量をそのまま使ってください。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  resource_detection:
    detectors: [env, system]   # EC2なら [ec2, env, system]
  cumulativetodelta: {}        # 累積メトリクスをデルタに変換

connectors:
  forward/traces_sample: {}
  span_metrics:
    aggregation_temporality: AGGREGATION_TEMPORALITY_DELTA
    dimensions:                # 実際はガイドの全項目を残す
      - name: deployment.environment.name
      - name: service.version
      - name: host.name
      - name: http.route

exporters:
  otlp_http:
    endpoint: https://otlp.${env:DD_SITE}
    headers:
      dd-api-key: ${env:DD_API_KEY}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [resource_detection]
      exporters: [forward/traces_sample, span_metrics]
    traces/sample:
      receivers: [forward/traces_sample]
      exporters: [otlp_http]   # tail_samplingはこの手前に置く
    metrics/span_metrics:
      receivers: [span_metrics]
      exporters: [otlp_http]
    metrics:
      receivers: [otlp]
      processors: [resource_detection, cumulativetodelta]
      exporters: [otlp_http]
    logs:
      receivers: [otlp]
      processors: [resource_detection]
      exporters: [otlp_http]

Contrib版とcore版の違いや、必要な部品だけで自作ディストリビューションを組む方法はOpenTelemetry Collector Contribとcoreの違いで解説しています。

span_metricsコネクタを外すとAPMのサービス画面が空になる理由

この構成でDatadog固有の処理を担うのがspan_metricsコネクタです。トレースからリクエスト数・エラー・所要時間のREDメトリクスを生成し、Service CatalogやService Page、Resource Pageの表示を支えます。コネクタを省くとトレース自体は届くのに、APMのサービス一覧に数値が出ない状態になります。

もう1つの要点は、トレースをforward/traces_sampleで分岐させている点です。REDメトリクスはサンプリング前の全トレースから計算し、サンプリングはDatadogへ送る側の枝だけに掛けます。テールベースサンプリングを複数台のCollectorで行うなら、同じトレースのスパンを同じCollectorへ集めるゲートウェイ構成が必要だとガイドは注記しています。サンプリング方式の違いはヘッドベースとテールベースのトレースサンプリングを、Kubernetesでエージェント層とゲートウェイ層を分ける設計はOpenTelemetryのKubernetes構成とCollector二層設計を参照してください。

既存のDatadog Exporter構成を使い続けるかの判断と非対応環境

Datadog ExporterとDatadog Connectorで組んだ既存構成には専用の設定ページが残されており、直ちに使えなくなるわけではありません。両部品は互換性ページで「Datadogが保守するコンポーネント」に分類されています。新規に組むならガイドの推奨どおりOTLP HTTP exporterで、既存構成は次のCollector更新のタイミングで載せ替えを検討する、という順番が現実的です。

なお、この構成はECS Fargate、EKS Fargate、AWS Lambdaのようなサーバーレスやタスク型のコンテナ実行環境には対応しないと明記されています。EKS FargateでCollectorを使うと、インフラのホスト課金が正しく計算されない点も注意書きがあります。

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

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

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

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

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

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

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

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

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

方式によって使える機能が変わる点は、契約範囲の説明で最も誤解を招きます。2026年9月時点の互換性一覧から、影響の大きい項目を抜き出します。Datadog SDK＋DDOTの組み合わせは、下表の全項目に対応済みです。

分散トレーシング、メトリクス・ログ・トレースの相関、Cloud SIEM、ランタイムメトリクス、スパンリンク、Agent Observabilityは、いずれの構成でも対応しています。落ちるのは主にプロファイリング・アプリ保護と、ホスト内部の可視化です。RUMはヘッダ注入でトレースと相関させる手順が別途案内されていますが、完全な機能はDatadog SDKの構成に限られます。

直接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を添えます。自動計装のアプリなら、OTelの標準環境変数だけで設定が完結します。

# トレースを直接インテークへ送る（gRPCは不可なのでhttp/protobuf）
export OTEL_EXPORTER_OTLP_TRACES_PROTOCOL="http/protobuf"
export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="（利用中のDatadogサイトのOTLPトレースエンドポイント）"
export OTEL_EXPORTER_OTLP_TRACES_HEADERS="dd-api-key=${DD_API_KEY},compute_stats=true"

エンドポイントはDatadogサイト（US1、AP1など）ごとに異なり、合っていないと403が返ります。日本のリージョンで契約している場合はサイトの取り違えを最初に疑ってください。

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のキーとして渡します。属性名の安定度の見分け方はOpenTelemetryのセマンティック規約と安定版の見分け方を参照してください。

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

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純正の計装を選ぶか、別のバックエンドを見るべきです。エラー監視を主目的に別の送信先を検討するなら、SentryへOTLPを送る3経路と機能の欠落が比較材料になります。

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

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

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

ベンダーロックインを避ける範囲を計装・収集・保存の3層で決める

ロックイン回避は全か無かで考えると判断を誤ります。計装（アプリのコード）、収集（Agent・Collector）、保存と分析（バックエンド）の3層に分け、どの層まで中立に保つかを決めてください。差し替えの手間が最も大きいのは計装層で、サービス数ぶんの改修とリリースが発生します。収集層は設定ファイルの差し替え、保存層は契約とダッシュボードの移設で済みます。

多くの受託案件で費用対効果が合うのは、1行目の「コードはOTel APIで書き、実装はdd-traceに任せる」構成です。Datadogの機能をほぼ失わずに、計装層の書き換えリスクだけを外せます。バックエンドの乗り換えが具体的な計画に上がっている場合に限り、2行目以降へ進んでください。費用面の比較をするときは、Datadogの料金体系と費用が膨らむ課金単位で示した課金単位を先に確認すると、乗り換えの損益が見積もれます。

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

Continuous Profilerでの継続的なプロファイリング、App and API Protectionによるアプリケーション保護、Data ObservabilityのJobs Monitoringが要件に入っているなら、OTel SDKでの計装一本の構成は見送りです。これらはDatadog SDKでの計装が前提になっており、機能を諦めるか計装を戻すかの二択になります。OTel APIでコードを書いておきdd-traceに実装させる構成なら両立できるため、この場面ではそちらへ寄せてください。

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

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

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

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

よくある質問

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

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

OTel SDKで計装した場合は使えません。分散トレーシング、メトリクス、ログの相関、Cloud SIEM、Kubernetes・インフラ監視は広く対応していますが、Continuous ProfilerやApp and API Protection、Data ObservabilityのJobs Monitoringは対象外です。コミュニティ版Collectorを使う場合はさらにDatabase MonitoringやLive Processes、Universal Service Monitoringも外れます。コードをOTel APIで書き、dd-traceに実装させる構成であれば、これらの機能も使えます。

dd-traceとOpenTelemetry SDKはどちらで計装すべきですか？

プロファイラ、アプリ保護、Data Streams Monitoring、RUMとの完全な相関のどれかが要件にあるならdd-traceです。その場合もDD_TRACE_OTEL_ENABLEDなどを有効にし、業務コードはOTel APIで書いておくと、将来の乗り換えで触る範囲を依存パッケージと起動設定に限定できます。バックエンドの乗り換えが具体的に決まっているならOTel SDKを選びます。同じプロセスで両方のSDKを混在させる構成は、公式が例外として定めた言語以外では避けてください。

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

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

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

トレースのインテークエンドポイントはHTTPのprotobuf形式とJSON形式に対応し、gRPCは非対応と明記されています。gRPCで送りたい場合は、Datadog AgentのOTLP受信（ポート4317）かCollectorを経由してください。なお直接インテークは本番ワークロードでは推奨されておらず、サーバーレスなど常駐部品を置けない環境向けの選択肢という位置づけです。DDOTはLinux上のKubernetesが前提のため、仮想マシン中心の環境では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とは何か：バックエンド側の機能構成と導入背景を、製品概要の粒度で確認できます。
• Datadog APM導入の実装手順：dd-traceの自動計装とサンプリング設計を扱う、計装ライブラリ側の実装記事です。
• Datadog Agent導入の実装手順：OTLP受信を開ける前提になるAgentの3方式とdatadog.yaml設定を確認できます。
• Cloud Traceとは：Google Cloud側でOTelを受ける場合の構成と料金で、Datadogとの比較材料になります。
• Application Insightsとは：Azure側のOTel受け口と料金体系で、マルチクラウド前提の選定時に併読できます。
• Bits AI SREの基本概要：連携後にDatadog側で使える運用自動化の位置づけを把握できます。