OpenTelemetry CollectorがDatadog形式のテレメトリ移行を分離

ClickHouseは、OpenTelemetry CollectorのDatadog receiverを使い、既存のDatadog SDKやエージェントを一度に置き換えずにテレメトリの送信先を移す方法を紹介しました。

要点

• DatadogのネイティブプロトコルをCollectorで受け、ログ、トレース、メトリクスをOpenTelemetryのデータモデルへ変換します。
• 収集コードの変更とバックエンド移行を分けられるため、段階的な切り替えとロールバックがしやすくなります。
• Collector側でフィルター、変換、バッチ処理、複数送信先への出力を組み合わせられます。
• ClickStackの費用対効果や導入事例の数値はベンダー主張であり、属性対応、相関、保存量、クエリー性能を自社データで確認する必要があります。

今回のブログ記事で語られていること

監視バックエンドを移すとき、最も大きな作業は送信先の設定だけではありません。アプリケーション内のSDK、ホスト上のエージェント、タグ付け、サービス間の相関、ダッシュボードやアラートが連動しているため、計装と保存基盤を同時に変えると原因の切り分けが難しくなります。改善されたDatadog receiverは、既存のDatadog SDKやエージェントが送るネイティブ形式をOpenTelemetry Collectorで受け、ログ、トレース、メトリクスをOpenTelemetryのデータモデルへ変換します。これにより、アプリ側の計装を維持したまま、出力先をClickStackなどへ変えられます。

Collectorのパイプラインでは、受信後に不要データの除外、属性の変換、バッチ化、複数バックエンドへの出力を設定できます。移行期間中は旧環境と新環境へ並行送信し、件数、欠落、属性、トレースとログの相関、アラート結果を比較できます。問題があれば送信経路を戻し、計装の置き換えは別の段階で進められます。この「収集の移行」と「バックエンドの移行」を分離できることが、記事の技術的な中心です。

公式記事はClickStackの高い費用効率を掲げ、Cleverの事例として月150TBを扱い、従来は10%を3日だけ索引化していたのに対し、ClickHouseでは全量を60日保持し、10倍圧縮、検索可能データ200倍を費用増加なしで実現したと紹介します。これらは個別条件でのベンダー事例です。移行判断では、保持量だけでなく、高カーディナリティ属性、取り込み遅延、ダッシュボード互換性、アラート再現性、個人情報の処理、Collector自体の可用性と容量を測る必要があります。AIエージェントによる障害調査に全履歴を使える利点も、データの完全性とアクセス制御が保たれて初めて成立します。

今回のブログ記事が関係する人

Datadogを利用するSRE、可観測性基盤チーム、OpenTelemetryの導入担当、ログ費用を管理するFinOps、障害調査エージェントを構築する開発者に関係します。

結局、今回のブログ記事をどう読むべきか

受信形式を互換層として使い、計装と保存先を別々に移すための実装案です。まず代表サービスを二重送信し、件数、属性、相関、アラート、費用を比較してから対象を広げるのが現実的です。