はじめに

こんにちは、Datadog Japan で Sales Engineer をしている AoTo です。

この記事は AoTo Advent Calendar 2023 7日目の記事です。

Datadog は OpenTelemetry に対応しているのか、何ができるのか、あまり知られていないかもしれません。結論から述べると Datadog は OpenTelemetry に対応しており、多くのことを実現できます。

2023年に発表された Datadog の OpenTelemetry をはじめとする OSS への取り組みの公式ブログをベースに、Datadog が OpenTlemetry で計装・収集した監視テレメトリデータをどのように扱えるのか紐解いていきます。

経緯

Datadog は Opentelemetry プロジェクトの発足前、StatsD をはじめとして OpenTracing や penCensus、OpenMetrics に対するサポートに注力してきました。

そのため、OpenTracing と OpenCensus が統合され OpenTelemetry としての単一プロジェクトの発足当初から、Datadog は独自の計装ライブラリをコミュニティに提供してきました。

OpenTracing と OpenCensus の統合に至る経緯は、Cloud Native Computing Foundation(CNCF) の記事から確認できます。

バックエンドとしての Datadog

OpenTelemetry はその特性から、データの保存と可視化は意図して他のツールに委任しています。この記述は OpenTelemetry の概要ページの最後「What OpenTelemetry is not」から引用したものです。

The storage and visualization of that data is intentionally left to other tools.

そのため、OpenTelemetry で計装・収集した監視テレメトリデータは何か知らのツールで保存・可視化する必要があり、Datadog がその最適な選択肢となるよう、様々な方法での統合がなされています。

監視テレメトリデータの取得

公式ドキュメントの「Datadog の OpenTelemetry」ページでは、OTel から監視テレメトリデータを Datadog に送信する方法を2つ紹介しています。

OTel Collector でデータを収集し、Datadog に送信

監視テレメトリの収集から Datadog への送信までを OTel Collector とそのディストリビューションの機能によって実現する方法です。

Datadog は OTel Collector の3つの主要コンポーネントである、Receiver と Processor、そして Exporter それぞれのディストリビューションが用意されています。

OTel Collector によって収集されたメトリクス・トレース・ログなどの監視テレメトリデータは、これらの内の Datadog Exporter によって Datadog バックエンドに送信することができます。これらのテレメトリデータは Datadog 上のプラットフォーム上で、Datadog ネイティブで取得されたものと同じように可視化することができます。

Datadog Agent でデータを収集し、Datadog に送信

Datadog Agent でも OTel SDK/Library によって計装・取得された監視テレメトリデータを収集し、Datadog バックエンドに送信することもできます。

OTel は汎用なテレメトリデータ配信プロトコルである OpenTelemetry Protocol(OTLP) を利用して監視テレメトリデータを配信しています。
Datadog Agent は OTLP で配信されたテレメトリデータを受け取れるよう、OpenTelemetry Collector OTLP レシーバー構成スキーマに従った Receiver が用意されています。この Receiver によって、gRPC/HTTP を通じた OTLP トレースと OTLP メトリクスの取り込みが可能となります。

監視テレメトリデータの可視化

Datadog は OTel によって計装・収集された監視テレメトリデータを、扱いやすくするためにさまざまな機能を備えています。

トレースデータのサンプリング

トレースデータのように、処理ごとに発生する大量のデータはその全てを収集する必要はなく、重要なデータの取り分けやネットワーク・保管コストの最適化のためにサンプリングを行うことも重要となります。

OTel SDK/Library や OTel Collector ではもちろん、Datadog Agnet や Datadog バックエンドによるサンプリングも行うことができます。

サンプリングを行う手法や場所でその効果や意味合いが変わってきますが、ヘッドベースサンプリングやテールベースサンプリングが必要に応じて実現できることを意味します。

OTLP ヒストグラムのヒートマップ

OTLP はヒストグラム形式のメトリクスをサポートしており、Datadog ではこうしたメトリクスの最適な可視化方法としてヒートマップをサポートしています。

OTLP ヒストグラムメトリクスは記録された測定値の母集団(合計、カウント、最小、最大などの集計統計情報)を圧縮形式で記録するメトリクスです。

ヒートマップウィジットはこうした母集団の集計統計情報を可視化するのに最適な手段で、視覚的にデータの特性や傾向を把握するのに役立ちます。

Datadog と OpenTelemetry の統合

Datadog はもちろん、単独での Observability を実現するプラットフォームとして様々な方式での監視テレメトリデータ収集が可能です。こうした Datadog によって取得されたテレメトリデータと OTel のテレメトリデータを必要に応じて紐づけることで、測定ツールに依存しない形での Observability が実現できます。

トレースの相互運用

Datadog では W3C Trace Context への対応をはじめとして、さまざまな方式で Datadog テレメトリデータと OTel テレメトリデータを統合する手法があります。

トレースコンテキストの伝搬

Datadog APM は、それぞれの言語のトレーシングライブラリのトレースコンテキストの伝搬によって、 B3 と W3C Trace Context のヘッダー抽出と挿入をサポートしています。¹

このように　Datadog APM は Datadog とは異なる形式のトレースコンテキストを受け取り、そのコンテキストを利用することができるため、アプリケーションの計装方法を単一のツールに依存することなく実装することが可能です。

128ビットトレースID

Datadog はトレースとスパン ID のフォーマットに、64ビットの符号なし整数を使用します。これに対し、W3C トレースは128ビットのトレース ID が暗黙的に含まれています。

Datadog の最新の APM ライブラリでは W3C Trace Context の推奨事項に従って、下位64ビットをランダムに生成する128ビットのトレース ID も生成するようにデフォルトで構成されています。²これにより、128ビットのトレース ID はもちろん、64ビットのトレース ID への下位互換性も提供します。

Datadog RUM との統合

Datadog RUM と APM の連携を利用することで、各 Datadog SDK はデフォルトで Datadog 形式の HTTP ヘッダーを挿入します。

Datadog RUM の OpenTelemetry のサポートにより、propagatorTypesやTracingHeaderTypeを追加することで W3C Trace Context の形式で HTTP ヘッダーを挿入します。

これにより、Otel によって計装されているアプリケーションであっても、Datadog RUM によって生成されたスパンと接続することができます。実際の画面としては、Dataog RUM の Session Explorer ページの各セッションから、単一のビューを選択して Trace タブを確認することで、対象の Flame Graph 確認できるようになります。

監視テレメトリデータ形式の統合

Datadog はバックエンドに収集された監視テレメトリデータにタグという形でディメンションを付与することで、Datadog の可視化機能によって情報の連携・絞り込み・集計・比較を行いやすくします。

統合サービスタグ付けは env、service、versionの3 つの予約済みタグにより、それぞれの情報の連携に利用できます。

セマンティック規則のマッピング

OTel ではセマンティック規則によってさまざまなデータタイプの名前を指定していますが、これを Datadog のタグに置き換える際のマッピングを公式ドキュメントで案内をしています。

一例として統合サービスタグ付けに使用される、予約済みタグは以下の表のようにマッピング可能です。

OPENTELEMETRY 規則	DATADOG 規則
deployment.environment	env
service.name	service
service.version	version

メトリクスのマッピング

Datadog は独自の命名パターンでメトリクスとタグを管理しています。Datadog に送信される OTLP メトリクスは、必要に応じて対応する Datadog メトリクスにマッピングされます。

OTLP メトリクスを Datadog メトリクスにマッピングするプロセス配下の通りで、自動的にマッピングされます。マッピングされる対象のメトリクスは、ホストメトリクスとコンテナのメトリクスにです。

デルタ一時性メトリクスの生成

OTel メトリクスは、大きく分けて「累積集計一時性」か「デルタ一時性」のどちらかの一時性を持つメトリクスを取り扱います。Datadog は StatsD をはじめとするデルタ一時性のメトリクスを中心に構成されており、OTel や Prometheus で生成される累積的な一時性のメトリクスから Processor を利用してデルタ一時性のメトリクスを生成することができます。

OTel Cumulative to Delta Processor は累積集計一時性からデルタ一時性に変換する OTel Processor であり、Datadog で表示するメトリクスに最適化することができます。

一時性について

一時性はメトリクスデータを定義するタイムスタンプに対して、集計対象の時間範囲を表す言葉です。

累積集計一時性とは、連続するデータポイントが開始タイムスタンプを繰り返すことを意味します。たとえば、開始時間 $T0$ から、累積データポイントは時間範囲 $(T0, T1]$, $(T0, T2]$, $(T0, T3]$ などをカバーします。
デルタ一時性とは、連続するデータポイントが開始タイムスタンプを進めることを意味します。たとえば、開始時間 $T0$ から、デルタデータポイントは時間範囲 $(T0, T1]$, $(T1, T2]$, $(T2, T3]$ などをカバーします。

つまり、累積集計一時性の場合、特定の開始時点からの累積時間全体の和などによって計算され、データの取得に失敗した期間は累積測定値から自然に平均化できるメリットがあります。
そして、デルタ一時性の場合、測定毎に対象の測定期間と値を更新することで計算され、サンプリングを行ったりデータのカーディナリティを低く保つことができるメリットがあります。

おわりに

上記では基本的な Datadog の OTel への対応をまとめましたが、細かい仕様についても Datadog による監視テレメトリの計装・収集を追随する形でサポートを拡大しています。

OTel を利用している場合は、監視テレメトリデータを可視化するバックエンドとして Datadog を検討いただければ嬉しいです🐶
OTel での情報が不足している場合にも、Datadog のプロダクトを利用して　Observability をシステムの隅々まで行き渡らせることができます🔭

Datadog と OpenTelemetry のさらなる発展を期待しましょう！

B3 は主に Zipkin で利用されており、W3C Trace Context　は OTel を中心に利用される標準化された仕様です。 ↩
この構成はDD_TRACE_128_BIT_TRACEID_GENERATION_ENABLEDをｔrueとすることで有効化されますが、最新のライブラリではデフォルトでｔrueとなります。 ↩