OpenTelemetry Collector を使った Datadog テレメトリの移行

Datadog移行をより速く始める方法 #

オブザーバビリティプラットフォームの移行は、データの保存先を変更するだけではありません。Datadogのエージェントやsdkは、すでに数千ものアプリケーション、ホスト、仮想マシン、Kubernetes Pod にまたがってデプロイされている可能性があります。別のバックエンドを評価する前にこれらすべての計装を置き換えるのは、移行の入り口で膨大なプロジェクトを抱え込むことになります。

OpenTelemetry Collector向けDatadog receiverの最近の改善により、アプリケーションは既存のDatadog SDKをそのまま利用し続けながら、デプロイ済みのエージェントの設定を変更してDatadogのネイティブプロトコルでreceiverへテレメトリを送信できるようになりました。receiverはログ、トレース、メトリクスをOpenTelemetryデータモデルに変換し、標準的なCollectorパイプラインを通します。

パイプラインに入った後は、テレメトリをフィルタリング、変換、バッチ処理し、サポートされている任意の宛先にエクスポートできます。チームは既存の収集インフラを運用し続けたまま、別のオブザーバビリティバックエンドを評価したり、より広範な移行を開始したりできます。

本記事では、Datadog receiverの改善内容と、OpenTelemetry Collectorがサポートする宛先への移行をどのように簡素化するかを、ClickStackを実例として見ていきます。

チームがDatadogからテレメトリを移す理由 #

多くのチームにとって、オブザーバビリティデータをDatadogから移す理由はコストです。アプリケーションが成長し、より多くのサービスが計装されるにつれ、ログとトレースの量は増えていきます。スケールが大きくなると、チームは支出を増やすか、生成したテレメトリの保持を減らすかの選択を迫られます。

そしてコスト制約は、調査時に利用できるものを左右します。チームはトレースをサンプリングしたり、ログをインデックスしなかったり、メトリクスを集約したり、保持期間を短縮したりします。これらの制御はいずれも、エンジニアが「何が起こったのか」を理解する必要があるときにクエリできるコンテキストを削減してしまいます。

ClickStack は、ストレージアーキテクチャの違いがこの計算をどう変えるかの一例です。ClickHouseの上に構築された、すぐに使えるオープンソースのオブザーバビリティプラットフォームで、OpenTelemetryネイティブの取り込みパイプラインと、ログ・メトリクス・トレース向けに専用設計されたインターフェースを組み合わせています。検索、ダッシュボード、アラート、トレース探索、AIアシスト調査を提供します。大規模なログおよびトレースワークロードでは、ClickStackはDatadogより100倍以上コスト効率が高い場合があります。これにより、チームは運用要件に応じて保持期間を設定し、後で必要になるかもしれないイベントを保持しておけます。

フルフィデリティのテレメトリは、エージェント型調査で特に役立ちます。エージェントは、調査開始前に破棄されたイベントについて推論できません。また、現在のインシデントを過去の障害、挙動の変化、長期的なパターンと比較するには、十分な履歴が必要です。

Cleverの移行事例はその違いを示しています。同社の400のサービスと200のAWS Lambda関数は、月あたり約150 TBの未圧縮ログを生成しています。Datadog使用時、Cleverはそのログの10%をインデックスし、3日間保持していました。ワークロードをClickHouse Cloudに移した後、すべてのログをインデックスし、保持期間を60日に延ばし、10倍の圧縮率を達成しました。エンジニアはコストを増やすことなく、200倍検索可能なログデータを手に入れました。

「ClickHouseでは、10倍の圧縮率を実現しています... これらのログはすべてのエンジニアが簡単にアクセスでき、Grafana、Athena、Datadogなど、どこに行けばいいか考える必要はありません。しかもこれらすべてが、コストの増加0%で実現しました。」

Jake Gutierrez、Clever社シニアソフトウェアエンジニア

オブザーバビリティプラットフォームを変更する隠れたコスト #

経済的メリットは魅力的でも、そこに到達するまでの道のりは大変に見えるかもしれません。大規模組織では、Datadog SDKで計装された数百のアプリケーションと、ホスト、Kubernetesクラスタ、仮想マシンにまたがってデプロイされた数千のDatadogエージェントが存在することがあります。これらすべてを計装とOpenTelemetryベースの収集レイヤーに置き換えるのは、それ自体が大きなプロジェクトになりかねません。

これは単に一つのエージェントを別のものに置き換えるだけの話ではありません。チームはOpenTelemetry Collectorをデプロイして設定し、アプリケーションの計装を更新し、ログ処理およびルーティングルールを作り直し、フィールドや相関が変更後も維持されることを検証する必要があるかもしれません。アプリケーションチームとインフラチームは異なるリリーススケジュールで動くことが多く、調整の取れた移行を短期間で完了させるのは困難です。

すでにOpenTelemetryへの標準化を決めているチームにとっては、この作業には価値があります。しかし他のチームにとっては、プラットフォーム移行と並行してこれをこなすのは負担が大きすぎるかもしれません。また、チームはコミットする前に新しいオブザーバビリティプラットフォームを評価できるべきです。収集レイヤーの移行とプラットフォーム移行を切り離せば、プラットフォームを素早く評価し、その後にOpenTelemetryを採用するか、既存の収集インフラを使い続けるかを独立して判断できます。

新スタックの評価中はDatadogエージェントをそのまま使う #

典型的なOpenTelemetryのデプロイでは、テレメトリはターゲットデータストアやオブザーバビリティソリューションに格納される前に、OpenTelemetry Collectorへ送信されます。Collectorは、Kubernetesのメトリクスやログを収集するエージェントモードのCollectorや、アプリケーションを計装するOpenTelemetry SDKからデータを受信します。Collectorは必要なフィルタリングや変換を適用し、イベントをバッチ化して、宛先へ送信します。

Collectorはさまざまな方法でデプロイできます。エージェントモードのCollectorはアプリケーションやホストの近くで実行でき、集約型のゲートウェイCollectorは多数のエージェントからOTLP経由でデータを受信します。より大規模になると、このゲートウェイ層が処理、ルーティング、バッチ処理を集中管理する場所となります。

Datadog receiver は、このアーキテクチャに新たな入力を追加します。receiverはしばらく前からOpenTelemetry Collector Contribディストリビューションに含まれており、DatadogのエージェントおよびSDKが使用するプロトコルを理解するエンドポイントを公開しています。受信したDatadogのペイロードをOpenTelemetryデータモデルに変換し、その後は通常のCollectorパイプラインを通ります。

したがって、既存のDatadogエージェントは、集約型のOpenTelemetry Collectorで動作するreceiverにログとトレースを送信するよう再設定できます。アプリケーションは既存のDatadog SDKをそのまま利用でき、インフラ全体にデプロイ済みのエージェントもそのまま維持されます。

DatadogテレメトリがCollectorパイプラインに入ると、処理してサポートされている任意の宛先にエクスポートできます。チームはストレージおよび分析バックエンドを変更しながら、既存のDatadogエージェントとSDKを維持できます。これを恒久的な収集経路として使い続けることも、時間をかけて段階的にOpenTelemetry計装へ移行することもできます。

同じセットアップは評価も容易にします。Collectorパイプラインは複数のエクスポーターを利用できるため、チームは同じテレメトリを既存のプラットフォームとClickStackなどの新しい宛先に並行して送信できます。両プラットフォームを同じデータで比較したうえで、移行するかどうかを判断できます。

ClickStackを使った実例 #

以下の例では、ClickStackを使い、既存のDatadogエージェントおよびSDKからのテレメトリを別のオブザーバビリティバックエンドへ移行する方法を示します。

ここでは、clickhouse/clickhouse-otel-collector として公開されているOpenTelemetry CollectorのClickStackディストリビューションを使用します。このディストリビューションはClickHouse向けに最適化されたデフォルト設定で維持されており、ポート8126でリッスンするよう設定済みのDatadog receiverが含まれています。

ClickStackは、HyperDXインターフェースで提供される取り込みAPIキーを使って取り込みを保護します。この値をDatadogエージェント/SDKにAPIキーとして渡すことで、ClickStack Collectorは受信したテレメトリを受け入れる前に認証できます。

以下の例では、Collectorの起動、Datadogエージェントの設定、ログとトレースをClickStackへ送信する方法を示します。

このデモでは Hacker Newsデモアプリ を使用します。手順に沿って進めたい場合は、datadog-instrumentation ブランチをクローンする必要があります:

1git clone --branch datadog-instrumentation https://github.com/ClickHouse/hn-news-analyzer.git

その後、READMEの手順 に従ってアプリを実行してください。

HackerNewsアプリのスクリーンショット

それが済んだら、オールインワンイメージ を使ってClickStackを起動します。このイメージには、ClickHouse、ClickStack UI (HyperDX)、そしてOpenTelemetry CollectorのClickStackディストリビューションが含まれています:

1docker run --name clickstack \
2  -p 8080:8080 \
3  -p 8123:8123 \
4  -p 4317:4317 \
5  -p 4318:4318 \
6  -p 127.0.0.1:18126:8126 \
7  -e ENABLE_DATADOG_RECEIVER=true \
8clickhouse/clickstack-all-in-one:latest

ここでは、Collectorコンテナのポート8126をホストのポート18126にマッピングしています。したがってDatadog receiverは http://127.0.0.1:18126 で利用できます。また、環境変数 ENABLE_DATADOG_RECEIVER でDatadog receiverを有効化する必要があります。

次に、Datadogエージェントをインストール します。Macでは以下のコマンドで実行できます:

1DD_SITE="datadoghq.com" bash -c "$(curl -L https://install.datadoghq.com/scripts/install_mac_os.sh)"

ダウンロードが完了したら、/opt/datadog-agent/etc/datadog.yaml を更新してトレースとログをClickStack OTel Collectorへ送信するようにします。

1api_key: "<YOUR_CLICKSTACK_INGESTION_KEY>"
2
3# Metrics destination
4dd_url: "http://127.0.0.1:18126"
5
6# ClickStack currently supports the Datadog v2 metrics intake.
7use_v3_api:
8  series:
9    enabled: false
10
11# Trace destination
12apm_config:
13  enabled: true
14  apm_dd_url: "http://127.0.0.1:18126"
15
16# Log destination
17logs_enabled: true
18
19logs_config:
20  logs_dd_url: "http://127.0.0.1:18126"
21  force_use_http: true
22
23# These require Datadog's backend, which we aren't using, so we disable them.
24remote_updates: false
25
26remote_configuration:
27  enabled: false

APIキーは、ClickStack UIに移動し、左下のユーザーを選択、Team Settings > API and Agents に進んで、Ingestion API Key をコピーすれば取得できます。

設定を更新したら、Datadogエージェントを再起動する必要があります:

1sudo launchctl kickstart -k system/com.datadoghq.agen

その後、ClickStack UIに戻り、Datadogエージェントが取得したトレース、ログ、メトリクスを探索できます。

改善への貢献 #

既存のレシーバーを実際のDatadog移行ワークロードに対して評価したところ、ログとトレースに影響するいくつかのギャップが見つかりました。作業の大部分は、Datadogのペイロードを適切なOpenTelemetry表現に変換することに注力しました。これにより、下流のシステムがDatadog固有のロジックを必要とせずに、データを解釈、相関付け、クエリできるようになります。

改善内容は以下の通りです:

• 正しいOpenTelemetryログレコード。 以前は、フィールドが文字列属性として書き込まれ、ログのタイムスタンプが設定されていなかったため、レコードがUnixエポックの時刻で表示されていました。レシーバーはDatadogのミリ秒タイムスタンプをナノ秒に変換し、OpenTelemetryのタイムスタンプ、観測タイムスタンプ、本文、重大度、リソースフィールドを設定するようになりました。
• リソース属性と重大度。 info、warn、errorなどのDatadogのステータスは、対応するOpenTelemetryのSeverityNumberおよびSeverityTextにマッピングされるようになりました。ホスト名、サービス名、環境、および既知のコンテナ、クラウド、Kubernetesのタグは、標準のリソース属性に昇格されます。ログはそのリソース単位でグループ化されます。
• トレースとログの相関。 dd.trace_idおよびdd.span_idフィールドは、OpenTelemetryレコードの実際のトレースおよびスパン識別子を設定するようになりました。レシーバーはまた、Datadogの分割表現から完全な128ビットのトレースIDを再構築します。この動作はデフォルトで有効になっており、Datadogから取得したログとスパンを、OpenTelemetryで計装されたサービスと相関付けできます。
• 構造化されたJSONログ。 Datadogエージェントは、JSONの前処理が通常Datadogバックエンドで行われるため、アプリケーションのJSONログを不透明な文字列として転送します。レシーバーはdecode_json_messageオプション(デフォルトで有効)を提供するようになり、この処理をCollector内で実行します。本文、タイムスタンプ、重大度、トレース識別子、リソースフィールド、および残りのログ属性を抽出します。
• 現行のDatadogエージェントとの互換性。 Datadog Agent 7.59以降は、デフォルトでHTTPペイロードをZstandardで圧縮します。レシーバーはgzipに加えてZstandardをサポートするようになり、現行のエージェントがペイロードを拒否されることなく接続できるようになりました。

これらの変更により、DatadogエージェントはOpenTelemetry Collectorに対して、相関付けされたOpenTelemetryネイティブなログ、メトリクス、トレースを送信できるようになります。

更新されたレシーバーは、ClickStack OpenTelemetry Collectorディストリビューションに含めています。これらの改善はすべて、上流のOpenTelemetry Collector Contribプロジェクトにも貢献しており、標準のContribディストリビューションを使用している方も利用できます。

現時点で移行できるもの #

DatadogレシーバーはOpenTelemetry Collector Contribにおいて依然としてalphaコンポーネントであり、そのためClickStack Collectorディストリビューションでも実験的機能としてマークされており、有効化には機能フラグが必要です。大規模な本番移行の基盤として推奨するには、まだ作業が必要です。

更新されたレシーバーをログおよびトレースのワークロードで広範囲にテストしており、ClickStackの評価用途としては安心して推奨できます。一方、メトリクスにはさらなるテストと開発が必要です。レシーバーは現在、Datadogのv1およびv2メトリクスインテークエンドポイントをサポートしています。新しいプロトコルバージョンを使用するエージェントデプロイメントは、サポートされているエンドポイント経由でメトリクスを送信するように明示的に設定する必要があります。今後も上流のOpenTelemetryプロジェクトを通じて、このカバレッジを改善していく予定です。

現時点では、アプリケーションがすでにDatadog SDKを使用している場合や、インフラストラクチャでDatadogエージェントが稼働している場合に、レシーバーはClickStackや他のオブザーバビリティプラットフォームを迅速に評価する手段を提供します。Collectorパイプラインは、同じログとトレースをDatadogと評価対象のプラットフォームの両方に送信できるため、両方のテレメトリパイプラインを並行して実行できます。チームは既存のDatadogパイプラインをそのまま維持しつつ、新しいプラットフォームでデータがどのように表現・クエリされるかを検証し、その後より広範な移行を進めるかを判断できます。評価で明確なメリットが確認できれば、同じアーキテクチャによって段階的な移行もサポートでき、既存のDatadog計装をそのまま維持しながら、サービスを時間をかけてOpenTelemetryへ移行できます。

まとめ #

これらの改善により、Datadogレシーバーはさまざまなオブザーバビリティプラットフォームでの幅広い利用に対応できる段階に達したと考えています。ClickStackのOpenTelemetry Collectorディストリビューションで提供できることを嬉しく思います。また、標準のContribディストリビューションを使用している方のために、変更を上流にも貢献しています。