TL;DR
- OpenTelemetry 以前は、ツールごとにばらばらなシグナルを集めていた。データの量、質、組み合わせの課題から、インシデントへの対応が遅れ、エンジニアは燃え尽き、品質が下がっていた。
- OpenTelemetry は、コンテキストとテレメトリの階層化によってテレメトリを統一し、この課題を解決する。
内容
OpenTelemetry 以前の課題
OpenTelemetry が登場する前の本番環境では、何十ものツールが出すさまざまなシグナルを、さまざまなフォーマットと周期で集め、保存と分析のために蓄えていた。
多くの組織は、ソフトウェアを理解しようとするときに、解析が必要なデータの量、データの質、データの組み合わせという 3 つの課題に直面する。その結果、インシデントの検出と復旧に時間がかかり、エンジニアは燃え尽き（バーンアウト）、品質は下がる。また、クラウド環境ではコードが実行されるノードが時間や分の単位で変わることがある。システムが急速に変化していると、多くのデバッグ手法が使いにくい。
この問題に対応するため、組織は幅広いツールを採用し、用途に合わせたメトリクスを集めて保存し、正規化している。大企業は大規模なマネージドプラットフォームでデータを集めるための独自のツールを使うが、これにはトレードオフがある。マネージドプラットフォームのコストは非常に高くなりやすく、移行にも高いコストがかかるため抜け出せなくなる。1 つのプラットフォームで解決できなければ、複数のプラットフォームや特定用途向けのツールの組み合わせを管理することになる。独自のプラットフォームを作る場合は、計装、収集、ストレージ、可視化の各レイヤを多大なコストをかけて作り直す、車輪の再発明が必要になる。
こうした課題は、高品質で、標準に基づいた、一貫性のあるテレメトリがないことから生じている。
コンテキスト
OpenTelemetry は、コンテキスト、テレメトリの階層化、セマンティックテレメトリの 3 つの特徴によってテレメトリを統一する。
コンテキストは、システムの操作とテレメトリとの関係を記述するメタデータである。出現する場所によって 2 種類に分かれる。
ハードコンテキストは、リクエストごとの一意な識別子である。分散アプリケーションの各サービスは、同じリクエストに関わる他のサービスにこの識別子を伝播（プロパゲーション）できる。このリクエストを論理コンテキストとも呼ぶ。ハードコンテキストはサービスとシグナルの関係を定義し、それによってシステム全体の形を定義する。
ソフトコンテキストは、同じリクエストを処理するさまざまなサービスやインフラストラクチャの測定値に、各計装が付けるメタデータである。顧客の識別子、ロードバランサのホスト名、テレメトリのタイムスタンプなどがある。ソフトコンテキストを使うと、特定のシグナルが何を表しているかを説明するための、シグナル間で共通のディメンションを作れる。
テレメトリの階層化
テレメトリは、よく時系列のメトリクスに変換される。しかし、この変換はリソースと時間の両方を消費する。リソースとしては CPU とメモリを使う。時間の面では、変換するデータが多いほど、結果を使えるようになるまでに時間がかかる。この作業はトイルであり、本番環境で何が起きているかを理解しにくくする。
これを避けるには、テレメトリのシグナルをレイヤに分け、互いに補い合うように使う方法がある。そうすれば、抽象度の異なるレイヤごとに、アプリケーションとシステムの振る舞いを計測できる。カスタマイズした計装を使い、コンテキストを通じてシグナルどうしをリンクし、重複するシグナルから正しいデータを得る。
OpenTelemetry はこの考え方を前提に作られており、シグナルはハードコンテキストでリンクされる。たとえば、メトリクスには特定の測定値を特定のトレースに結びつけるイグザンプラー（exemplar）を付けられる。ログは、処理されるときにトレースのコンテキストと関連づけられる。これにより、スループット、アラートの閾値、SLO や SLA などをもとに、どのデータを出力し保存するかを適切に決められるようになる。