はじめに

OpenTelemetry（OTel）は、メトリクス・ログ・トレースといったテレメトリデータを標準的な形式で収集・送信するための仕組みです。

2026年5月には CNCF の Graduated プロジェクトとなり、クラウドネイティブ環境におけるオブザーバビリティの標準として、さらに存在感が増しています。

Datadog でも OpenTelemetry への対応が進んでおり、OTel 形式のデータを Datadog 上で扱いやすくする OpenTelemetry-native な流れが出てきています。

ただ、既に Datadog を使って監視運用している環境では、単純に「OpenTelemetry に対応したので使ってみよう」だけでは少し危険だと感じます。

実際の運用では、データを送信できるかどうか以上に、以下のような点が重要になるためです。

  • 既存の Datadog Monitor や Dashboard に影響が出ないか
  • service、env、version などのタグ設計をどう揃えるか
  • APM、ログ、メトリクスを今まで通り横断できるか
  • Kubernetes やクラウドリソースとの紐づきが崩れないか
  • タグの増加によってコストや検索性に影響が出ないか

本記事では、Datadog の OpenTelemetry-native 対応を「新機能紹介」としてではなく、既存の Datadog 運用に OpenTelemetry を取り入れる場合の判断ポイントとして整理します。

OpenTelemetry-native 対応で期待できること

Datadog は以前から OpenTelemetry Collector 経由でデータを受け取ることができました。

OpenTelemetry-native 対応で期待できるのは、単に OTel データを取り込めるだけではなく、Datadog の APM、Infrastructure、Kubernetes Explorer などの画面で、より自然に扱えるようになることです。

たとえば、OpenTelemetry ではサービス名や環境名を以下のような属性で表現します。

OpenTelemetry の属性 Datadog 側での扱い
service.name service
deployment.environment.name env
service.version version
cloud.provider cloud_provider
cloud.region region

この対応関係が整理されていることで、OTel SDK で計装したアプリケーションでも、Datadog の Unified Service Tagging に近い考え方で扱いやすくなります。

つまり、OpenTelemetry を使うから Datadog の運用体験を捨てる、という話ではありません。

むしろ、アプリケーション側の計装は OpenTelemetry に寄せつつ、調査・可視化・通知は Datadog の機能を活用する、という構成を取りやすくなってきています。

まず考えるべきは「置き換え」ではなく「併用」

既に Datadog Agent を使っている環境で、いきなり全面的に OpenTelemetry へ移行する必要はないと思います。

Datadog Agent には、ホストメトリクス、コンテナメトリクス、ログ収集、各種インテグレーションなど、Datadog らしい強みがあります。

一方で OpenTelemetry には、言語やベンダーに依存しにくい計装、Collector による送信先制御、複数バックエンドへの展開しやすさといった強みがあります。

そのため、現実的には以下のような併用から始めるのがよさそうです。

  • 既存のホスト・コンテナ監視は Datadog Agent を継続する
  • 新規アプリケーションのトレース計装は OpenTelemetry SDK を検討する
  • OTel Collector から Datadog へ送信し、表示やタグの揃い方を確認する
  • 問題がなければ対象サービスを徐々に増やす

OpenTelemetry は Datadog の代替というより、計装とデータ配送を標準化するレイヤーとして考える方が扱いやすいです。

構成パターンの比較

Datadog で OpenTelemetry を使う場合、主に以下の構成が考えられます。

構成 特徴 向いているケース
Datadog Agent 中心 Datadog の既存機能との親和性が高い Datadog を主監視基盤として使い続ける環境
Datadog Agent + DDOT Collector Datadog の機能を活かしつつ OTel データも扱う 既存 Datadog 運用に OTel を段階導入したい環境
Community OTel Collector + Datadog Exporter 標準的な OTel Collector 構成を維持できる 既に OTel Collector を運用している環境
Direct OTLP Ingest アプリケーションや Collector から Datadog に直接送信する 小規模検証やシンプルな構成で始めたい場合

運用目線で比較すると、以下のようになります。

観点 Datadog Agent 中心 OTel Collector 中心
導入しやすさ Datadog 前提なら始めやすい Collector の設計・運用が必要
Datadog 機能との親和性 高い 構成や属性設計に左右される
ベンダーニュートラル性 やや低い 高い
タグ設計 Datadog の流儀に寄せやすい OTel のセマンティック規約を意識する必要がある
複数バックエンド連携 Datadog 中心 Collector で分岐しやすい
運用負荷 比較的低い Collector 自体の監視・更新が必要

個人的には、既に Datadog を中心に運用している環境であれば、最初は Datadog Agent + DDOT Collector の構成から検討するのが無難だと感じます。

Datadog の既存機能を活かしながら、OpenTelemetry のデータをどのように扱えるかを確認しやすいためです。

既存 Datadog 環境に入れるときの論点

サービス名が揃うか

APM やログ、メトリクスを横断して見るうえで、サービス名は非常に重要です。

Datadog では service タグ、OpenTelemetry では service.name がサービス名に相当します。

ここが既存の命名とずれると、APM の Service Catalog や Monitor、Dashboard で別サービスとして扱われてしまう可能性があります。

たとえば、既存 Datadog 環境で service:web-api として運用しているのに、OpenTelemetry 側で service.name=web_api と設定してしまうと、画面上では別物として見えてしまいます。

OTel 導入時は、まず既存の service タグ一覧を確認し、OpenTelemetry 側の service.name と命名規則を合わせることが重要です。

env と version が揃うか

Datadog の Unified Service Tagging では、service、env、version の3つが重要です。

OpenTelemetry では、それぞれ以下のように対応させます。

Datadog OpenTelemetry
service service.name
env deployment.environment.name
version service.version

特に env は Monitor や Dashboard の条件に使われていることが多いため、prod、production、prd のような表記揺れがあると運用に影響します。

OpenTelemetry 側の設定を決める前に、既存の Datadog タグを棚卸ししておくとよいです。

Monitor や Dashboard への影響

既存の Monitor や Dashboard が Datadog のタグを前提にしている場合、OpenTelemetry 導入後に期待したデータが表示されない可能性があります。

特に以下のようなクエリを使っている場合は注意が必要です。

  • service タグで絞り込んでいる Monitor
  • env タグで本番・検証環境を分けている Dashboard
  • Kubernetes の namespace や pod_name を使っているグラフ
  • APM メトリクスを前提にした SLO

OpenTelemetry 導入時は、単にデータが届いたことを確認するだけではなく、既存の Monitor や Dashboard に期待通り反映されるかまで確認した方がよいです。

ログ・メトリクス・トレースを横断できるか

Datadog の強みの一つは、ログ、メトリクス、トレースを横断して調査できる点です。

OpenTelemetry を導入した結果、トレースは見えるがログと紐づかない、メトリクスは届くがサービスページに集約されない、という状態になると、障害対応時の使い勝手が落ちてしまいます。

そのため、検証では以下を確認するとよいです。

  • APM のサービスページに表示されるか
  • Trace Explorer で service や env で検索できるか
  • 関連ログへ遷移できるか
  • サービス単位のメトリクスとトレースを同じ軸で確認できるか

タグ設計で気をつけたいこと

OpenTelemetry は属性を柔軟に付与できます。

ただし、自由に付けられるからといって、何でもタグとして使うと後で運用が難しくなります。

最初に揃えたいタグ

まずは以下を必須として揃えるのがよさそうです。

目的 OpenTelemetry 属性 Datadog 側の見え方
サービス識別 service.name service
環境識別 deployment.environment.name env
バージョン識別 service.version version
チーム・システム識別 team、system など 任意タグ

team や system は OpenTelemetry の標準属性だけで完結しない場合もありますが、運用上はかなり重要です。

特に複数チームで Datadog を利用している場合、アラートの通知先やコスト配賦、ダッシュボードの整理に使えます。

慎重に扱いたいタグ

以下のような値は、タグとして扱うとカーディナリティが高くなりやすいです。

  • user ID
  • request ID
  • session ID
  • transaction ID
  • フル URL
  • 動的なファイル名
  • ランダムなジョブ ID

これらは調査には便利ですが、メトリクスタグとして大量に使うとコストやパフォーマンスに影響する可能性があります。

「トレースやログの属性として持つ」のか、「メトリクスのタグとして集計軸にする」のかは分けて考えた方がよいです。

コスト面で見ておきたいポイント

OpenTelemetry を導入すると、今まで取得していなかったデータが簡単に取れるようになります。

これは便利な反面、意図せず送信量やタグ数が増える可能性があります。

特に注意したいのは以下です。

観点 確認ポイント
メトリクス 送信するメトリクス数、タグ数、カーディナリティ
ログ OTel Collector 経由で転送するログ量、除外ルール
トレース サンプリング設定、Span 数、保持したい属性
Collector Collector 自体のリソース使用量、冗長化、監視

OpenTelemetry Collector は便利ですが、Collector を入れることで新しい運用対象が増える点も忘れない方がよいです。

Collector が停止すると、その経路で送信しているテレメトリデータが欠落する可能性があります。

そのため、本番利用する場合は Collector 自体のメトリクス監視、ログ確認、冗長化も検討が必要です。

小さく検証するなら

最初から Kubernetes 環境全体に導入するのではなく、まずは小さな構成で確認するのがよいです。

おすすめは、1つのサンプルアプリケーションから OTel Collector 経由で Datadog にトレースやメトリクスを送信する構成です。

検証では、以下の順番で確認すると実運用に近い判断がしやすくなります。

順番 確認内容 見るポイント
1 Datadog にデータが届くか Trace Explorer、Metrics Explorer で確認
2 サービス名が期待通りか service.name が既存命名と合っているか
3 環境タグが期待通りか deployment.environment.name が env として使えるか
4 既存 Monitor に影響がないか service、env 条件で拾えるか
5 タグが増えすぎていないか Metrics Summary やタグ一覧で確認
6 ログ・トレースが紐づくか 障害調査時の導線を確認

ここまで確認できれば、「OpenTelemetry で Datadog に送れる」だけでなく、「既存運用に載せられるか」を判断しやすくなります。

Kubernetes での検証は、その次の段階でよいと思います。

導入してよさそうなケース

OpenTelemetry の導入が向いていそうなのは、以下のようなケースです。

  • 新規サービスで、最初から標準的な計装を入れたい
  • 複数言語・複数フレームワークで計装方式を揃えたい
  • Datadog 以外のバックエンドにも将来的に送信する可能性がある
  • マイクロサービス間のトレースを標準化したい
  • Kubernetes 環境でテレメトリの収集方式を整理したい

逆に、既存の Datadog Agent と各種インテグレーションだけで十分に運用できている小規模環境では、OpenTelemetry を急いで導入する必要はないかもしれません。

Collector の運用やタグ設計の整理が増えるため、得られるメリットと運用負荷を比較して判断した方がよいです。

個人的な所感

Datadog の OpenTelemetry-native 対応は、OpenTelemetry を利用するうえでかなり心強い流れだと思います。

ただし、既存の Datadog 環境に対しては「OpenTelemetry に置き換える」というより、「OpenTelemetry でも Datadog の運用体験を崩さずに扱えるようになってきた」と捉えるのがよさそうです。

特に重要なのは、データの送信方式よりも、サービス名・環境名・タグ設計・Monitor への影響です。

ここを整理せずに導入すると、Datadog 上ではデータが見えているのに、既存の Dashboard やアラートでは使いにくい、という状態になりかねません。

まずは新規サービスや検証環境で OpenTelemetry の属性設計を固め、Datadog 上で期待通りに見えることを確認する。そのうえで対象を広げるのが現実的だと感じました。

まとめ

Datadog の OpenTelemetry-native 対応によって、OpenTelemetry で収集したデータを Datadog 上でより扱いやすくなってきています。

一方で、既存運用に取り入れる場合は、単に「データが送れるか」だけでなく、以下を確認することが重要です。

  • 既存の service、env、version と揃っているか
  • Monitor や Dashboard の条件に影響がないか
  • ログ・メトリクス・トレースを横断して調査できるか
  • タグの増加やカーディナリティによるコスト影響がないか
  • Collector 自体の運用負荷を許容できるか

OpenTelemetry は Datadog の代替ではなく、計装とデータ配送を標準化するための選択肢です。

Datadog を主な監視基盤として使い続ける場合でも、OpenTelemetry をうまく取り入れることで、将来的な拡張性やベンダーニュートラル性を高められると感じました。

参考