はじめに
こんにちは、Datadog Japan で Sales Engineer をしている AoTo です。
本投稿は OpenTelemetry Advent Calendar 2024 8日目の記事です。
Datadog で OpenTelemetry によって計装されたメトリクス・トレース・ログを扱うためにはさまざまな観点での考慮事項が必要となります。こうした複雑な考慮事項を紐解くために、計装対象のシステムからメトリクス・ログ・トレースを収集し Datadog のバックエンドに転送するまでを網羅的に図解し、各手法について解説します。
Datadog と OpenTelemetry の関係は、2023年12月にも『Datadog って OpenTelemetry に対応しているの？』でも解説しているため、併せてご覧ください。
【図解】 OpenTelemetry × Datadog
現在の Datadog の OpenTelemetry(OTel) との関係を図解すると、以下のになります。
昨年からの大きな追加点は、OpenTelemetry API による手動計装(custom instrumentation) と Datadog Agent に埋め込まれた OpenTelemetry Collector です。
OTel SDK, OTel API, Propagation(伝搬) のそれぞれの切り口で解説します。
OTel SDK
まずは、各言語の OpenTelemetry SDK でトレースの計装をする場合を考えます。OTel はトレースを OTLP(OpenTelemetry Protocol) で転送します。この転送先としては大きく①OpenTelemetry Colloctor へ転送するか②Datadog Agent へ転送するかを検討します。
①OpenTelemetry Colloctor への転送
OpenTelemetry Colloctor(OTel Col) へ転送する場合、OTel Col はこれらのトレースを OTLP Receiver で受け取ります。さらに、Datadog バックエンドに転送するには Datadog Exporter が必要です。
Datadog Exporter はトレース・メトリクス・ログの全てをの標準の Datadog API エンドポイントへデータを変換し送信します。具体的には、Datadog の統合サービスタグ付けに準拠したタグの付与が挙げられます。
②Datadog Agent への転送
Datadog Agent(DDAgent) へ転送する場合、DDAgent の受け取り方は2通りあります。
1つ目は従来の受け取り方で、DDAgent 内の Agent, Tracer Agent が 4316/tcp, 4317/tcp でトレースを受け取り、内部で適切に変換し Datadog API エンドポイントに送信します。
2つ目は「DASH 2024」で発表された新しい方法で、DDAgent 内に埋め込まれた OTel Col を利用する方式です。この場合、Datadog OpenTelemtry Collector という名前の Distribution が Datadog によって用意され、ベンダー中立的な Receiver, Processor, Exporter, Connector がこれらに含まれます。面白い点としては、この Exporter に Datadog Exporter も含まれず、Datadog には OTLP Exporter によってデータが送信されます。
今後の展開
独自の OTel Col をビルドして、Datadog Exporter でデータを Datadog に送信する方式は引き続きサポートされることが予想されます。一方で、現状は Preview の DDAgent に埋め込まれた OTel Col は今後最も推奨される方式となることが予想されます。
これは、OpenTelemetry のエコシステムがサポートするトレース・メトリクス・ログ(・プロファイラー)などのテレメトリ以外の、ネットワーク・セキュリティ・LLM などの Datadog 独自のテレメトリの収集を実現しつつベンダー中立的な基本的な監視データ収集が実現できるためです。
さらに、DDAgent を利用することでその機能である Fleet Automation によるバージョン・構成・設定の管理や、Remote Flare の利用による迅速な Datadog サポートの利用など Datadog エコシステムの恩恵を多大に受けられます。
さらに、現状は機能として提供されていませんが、Remote Confituration による Datadog からの OTel Col の構成・設定変更が可能になれば、OpAMP(Open Agent Management Protocol) での Supervisor や Server に悩まされることなく柔軟な構成変更が実現できます。
OTel API
続いて、OpenTelemtry によるアプリケーション計装の仕様である OpenTelemetry API との関係を見ていきましょう。
Datadog APM は各言語でライブラリの実装のみで自動的に特定のライブラリ・フレームワークの動作を計装する自動計装から簡単に初めていただけます。しかし、より詳細な要件が生まれると、手動計装による独自のスパンの作成やスパンタグの挿入が不可欠となります。
こうした際に、従来の Datadog APM は OpenTracing ライブラリをもとにした手動計装の方式などを実装していました。しかし、最新では Datadog APM が対応するすべての言語で OTel API サポートが実装され、手動計装の記載を OTel ライブラリを用いた方式で行えます。
OpenTelemetry Incubating API は含まれません。
さらに、手動計装だけでなく Datadog APM SDK が対応していない自動計装を、OTel 互換 の 計装ライブラリで計装することが可能です。
これらの OTel API への対応・互換性の拡張により、Datadog, OpenTelemetry の両方の特性やメリットを活かした計装が実現できます。さらに、この場合もベンダー中立なメリットとして、コードへの手動計装の記載が Datadog に依存しない方式とできます。
Propagation(伝搬)
最後に、各実装の相互運用性を高めるための Propagation(伝搬) についても整理します。
Datadog APM, RUM はどちらも W3C Trace Context に準拠した方式での HTTP ヘッダーの受け渡しが可能です。これはつまり、Datadog RUM SDK から OTel SDK への traceparent, tracestate 伝搬フィールドの受け渡しができ、さらに OTel SDK から Datadog APM SDK へも同様です。
実際には Datadog RUM は W3C Trace Context に準拠した HTTP ヘッダーを発行し、OTel SDK はこれを受け取ることで親スパンを Datadog RUM SDK によって生成されたスパン ID として記録します。
同様に、Datadog APM SDK は W3C Trace Context に準拠した HTTP ヘッダーを受け取ると、独自の x-datadog-trace-id と共に、traceparent, tracestate の伝搬フィールドも受け渡します。これにより、後続に OTel SDK, Datadog APM SDK のどちらで実装されたアプリケーションがあっても、トレースを伝搬し Datadog 上で単一のトレースとして可視化できます。
こうしたトレースコンテキストの適切な受け渡しがに Datadog の各 SDK が準拠することで、組み合わせに苦慮することなくさまざまなアプリケーション間の分散トレースが実現できます。
おわりに
OpenTelemetry × Datadog で現在説明できるすべての組み合わせを入れ込んだ図を作成したいというモチベーションから本記事を執筆しました。
本記事の中で唯一触れられていない機能として、Datadog バックエンドでの OTLP メトリクスの直接取り込みがあります。
本機能は、OpenTelemetry Collector や Datadog Agent を利用できず直接メトリクスを送信する必要がある限定されたユースケースの場合にのみ利用が推奨されており、基本的にはゲートウェイ型の実装であればこれを回避できます。
そのため、積極的には紹介しませんでしたが明確なユースケースがある場合は是非 Preview に申請しご利用の上、ユースケースを共有いただけると嬉しいです🐶