OpenTelemetryとは何か? ベンダー中立なテレメトリの解説
OpenTelemetry(しばしばOTelと略される)は、テレメトリ(metrics、logs、traces)を生成、収集、エクスポートするための、ベンダー中立なオープン標準およびtoolkitです。
OpenTelemetryは、アプリケーションがオブザーバビリティのデータを生成する方法を統一するCNCFのプロジェクトです。それ以前は、各ベンダーが独自のagentとSDKを持っていたため、ツールを切り替えることはコードの再計装を意味しました。OTelは計装をバックエンドから切り離すため、一度計装すれば、データを好きな場所に送れます。
解決する問題
歴史的に、オブザーバビリティのベンダーを採用することは、そのベンダーのSDKをコード全体に埋め込むことを意味しました。ツールの変更はコストのかかる書き直しであり、そのlock-inが狙いでした。OpenTelemetryは、データモデル、計装対象のAPI、ワイヤーフォーマットを標準化することで結合を断ち、バックエンドの選択を設定の詳細にします。
コンポーネント
- APIとSDK: spanの作成、metricsの記録、logsの発行に使う言語ライブラリ。
- 計装: フレームワークや自分のコードからテレメトリを捕捉する自動および手動のフック。
- Collector: テレメトリを受信、処理し、一つ以上のバックエンドへエクスポートするスタンドアロンのサービス。
- OTLP: OpenTelemetry Protocol、データを送るための標準フォーマット。
traces、metrics、logsを一緒に
OTelは、3つのシグナルすべてをファーストクラスかつ相関可能として扱う数少ない標準の一つです。traceは、関連するlogの行にタグ付けするのと同じコンテキストを運べるため、遅いtraceからそれが生成した正確なlogsへピボットできます。この相関が、現代のオブザーバビリティを強力にしているものの多くです。
Collector
CollectorはOTelの中心的な配管です。アプリケーションはそれにテレメトリを送り、それがデータをバッチ化、フィルタ、拡充し、設定した任意のバックエンドへ扇状に配ります。Collectorを運用することは、アプリケーションのコードに一切触れることなく、その設定を編集するだけでオブザーバビリティのベンダーを切り替えたり追加したりできることを意味します。
CI/CDにおけるOpenTelemetry
拡大しつつあるパターンは、pipeline自体をOTelで計装し、pipelineの実行をtraceとして、各jobやステップをspanとしてモデル化することです。その結果、buildが時間をどこで費やすかのflame graphビューが得られます。OTelはベンダー中立なので、同じpipelineのテレメトリを、チームがすでに運用している任意のオブザーバビリティスタックに流し込めます。
なぜ重要か
OpenTelemetryは、あらゆる主要なオブザーバビリティのベンダーに支持される、計装の事実上の標準になりました。それを採用することでテレメトリが将来にわたり通用するものになります。コードがどう計装されるかの所有権を保ち、再計装なしにツールを変更する自由を保てます。
重要なポイント
- OpenTelemetryは、metrics、logs、tracesのためのベンダー中立な標準です。
- 計装をオブザーバビリティのバックエンドから切り離します。
- Collectorは設定だけでテレメトリを任意のバックエンドへルーティングします。
- build時の分析のために、pipelineの実行をtraceとしてモデル化できます。