「垂直統合」から「水平分業」へ──従来型監視ツールとの構造的な違い
──日本の現場では、従来型の監視ツールが根強く使われています。これらとOpenTelemetryの決定的な違いは何でしょうか。
Ted：根本的な違いは、構造が「垂直統合」か「水平分業」か、という点にあります。従来の監視ツールは、データの収集から保存、可視化までが「垂直統合」され、サイロ化していました。OpenTelemetryはこれを「水平方向」に分離します。「データの生成・収集」部分はOpenTelemetryという世界標準のオープンソースで行い、一方で分析の部分はユーザーが自由に選べるようにするのです。
これは、ベンダーを切り替えるたびにコードベース全体を再インストルメント（計装し直し）しなければならなかった従来のサイロ化モデルよりも優れたアプローチです。
──OpenTelemetryは世界的にどの程度普及しているのでしょうか？
Ted：OpenTelemetryはCNCF（Cloud Native Computing Foundation）の中で2番目に大きなプロジェクトです。Linux Foundation全体で見ても、Linux、Kubernetesに次いで3番目に大きなプロジェクトとなっています。
──日本ではPrometheusも人気があります。OpenTelemetryとの関係性についてはいかがでしょうか。
Ted：PrometheusとOpenTelemetryは、CNCF（Cloud Native Computing Foundation）の中での「姉妹プロジェクト」のような関係です。どちらもメトリクスを扱っており、相互運用性を重視しています。実際に、OpenTelemetryはPrometheusクライアントと連携できるように設計されています。多少のセットアップは必要かもしれませんが、すべてが連携して動作します。将来的には、これらのプロジェクトをさらに近づけていきたいと考えています。
価値あるデータのみを残すために──OpenTelemetryのアプローチ
──Grafana Labsの調査によると、日本の組織の80%以上がツール選定で「コスト」を最重要視しています。データ量が増加する中、OpenTelemetryでコストを制御する具体策はありますか。
Ted：コストは世界共通の課題ですが、特にデータ量が増え続ける現代においては切実です。コスト削減の鍵は、「価値のあるデータは残し、それ以外は捨てる」ことにありますが、それを実装段階で判断するのは困難です。かといって、人間が手動でサンプリングルールを設定するのもおすすめしません。「後で何が重要になるか」は事前には分からないからです。どのデータが価値あるものかを理解しているのは「バックエンドツール」です。
私たちが現在開発している「OpAmp（Open Agent Management Protocol）」というプロトコルでは、設定やサンプリングルールをOpenTelemetry Collectorにプッシュ（配信）できるようになります。
Grafana Labsでは、OpAmpなどのOpenTelemetryの仕組みを活用し、テレメトリー量を動的に制御する一連の機能を「Adaptive Telemetry（適応型テレメトリー）」と呼んでいます。バックエンドがデータの流れを分析し、「この種類のデータは多すぎるから間引こう」「この稀なデータはもっと必要だ」と指示を出します。静的なルールを書くよりもはるかに効率的です。
──ベンダーロックインについて、OpenTelemetryはどのように技術的な独立性を保つことができるのでしょうか。
Ted：ベンダーニュートラル（中立性）はOpenTelemetryの核心です。 第一に、インストルメンテーションが特定ベンダーのバックエンドに紐づいていると、切り替えは大変です。テレメトリーを標準化することで、コードを変更することなくバックエンドを切り替えることが可能です。
第二に、プロジェクトのガバナンスです。OpenTelemetryはCNCF内で厳格なルールがあり、特定の1社がプロジェクトを支配しないようになっており、中立性を保っています。
