深夜のアラート、3つの画面を往復する30分
深夜、K3sクラスタでレイテンシ悪化のアラートが鳴る。まずPrometheusでどのサービスのP99レイテンシが跳ねているかを確認し、次にLokiで該当時間帯のエラーログを検索し、最後にJaegerでどのリクエストが遅かったかを突き合わせる。
この「3つのダッシュボードを往復する」作業は、多くのチームにとって当たり前の光景になっている。Grafana Labsが2025年に実施した調査では、企業は平均8種類の可観測性ツールを併用し、合計101種類もの異なる可観測性技術が挙げられたという（Grafana Observability Survey 2025）。ツールが増えるほど、障害調査は「推測とタイムスタンプの突き合わせ」に頼るしかなくなる。
本記事では、この「サイロ化した可観測性」がなぜ生まれるのか、そしてメトリクス・ログ・トレースを相関（＝バラバラの手がかりを1つの原因につなぎ合わせること）させる設計にどう移行すべきかを解説する。
ツールを増やすほど障害対応が遅くなるという逆説
可観測性の「三本柱」と呼ばれるメトリクス・ログ・トレースは、それぞれ別のツールで扱われることが多い。Prometheusでメトリクスを、Lokiでログを、Jaegerでトレースを、という構成は一見合理的だが、別々のデータストアに保存され共通の識別子で紐付いていない場合、障害対応の現場では致命的な非効率が生まれる。
Network Worldが報じた調査によれば、企業は依然として平均4.4個の可観測性ツールを運用しており、ネットワーク運用チームの87%が「意味のある統合のないまま複数ツールに依存している」と回答している（Network World）。影響度の高い障害1件あたりのコストは中央値で1時間200万ドルにのぼるが、フルスタックの可観測性を実現した組織では半減するという。ツールの数ではなく、シグナル間の相関が取れているかが障害対応コストを左右する。
Grafanaの調査でも、アラート疲れが「ほぼ全ての職位で障害対応を遅らせる最大の要因」として挙げられ、複雑性そのものが39%の回答者にとって最大の障壁になっている。ツールを個別最適で増やした結果、全体では障害対応が遅くなるという逆説がここにある。KuboのようなマネージドK3sサービスには、可観測性スタックを最初から統合設計で提供するものもある。
OpenTelemetryがKubernetesに次ぐ規模のプロジェクトに成長した理由
この「サイロ化した可観測性」への回答として急速に普及しているのがOpenTelemetry(OTel)だ。CNCFは2026年5月、OpenTelemetryを最上位ステータスである「Graduated（卒業)」プロジェクトに認定したと発表した（CNCF公式発表）。プロジェクトページによれば参加企業は5,136社、総貢献者数は26,846名にのぼり（CNCF Projects: OpenTelemetry）、CNCF傘下240以上のプロジェクトの中でもKubernetesに次ぐ第2位のプロジェクト速度という分析もある。
この成長の背景には、単なる人気ではなく設計思想の転換がある。OpenTelemetryは「メトリクス・ログ・トレースを別々のツールで個別に集める」のではなく、単一の計装標準でこれら3つのシグナルを収集し、共通のコンテキスト（トレースID等）で紐付ける前提で設計されている。ベンダー固有の計装ライブラリに縛られず、バックエンドを乗り換えても計装コードを書き直す必要がなく、ベンダーロックインを避けたいインフラチームの導入動機になっている。
メトリクスとトレースを「クリック1つ」でつなぐExemplarsという仕組み
この相関を技術的に支えるのが「Exemplars」という仕組みだ。メトリクスのサンプルにトレース情報（trace_id・span_id・timestamp）を直接紐付けるデータ構造で、アクティブなスパンのコンテキスト内で記録されたメトリクスに自動でトレース識別情報が付与される（OpenTelemetry公式ドキュメント: Exemplars）。
Exemplarsがない状態でレイテンシスパイクを検知しても「何かが遅い」ことしか分からず、ログを手動で検索し30分以上かかることも珍しくない。Exemplarsを使えば、グラフ上の異常値をクリックするだけで実際のトレースへ直接ジャンプできる。ある実装ガイドでは、根本原因の特定が2分程度まで短縮された事例が紹介されている（metric-trace correlationの実装ガイド）。
Google CloudのManaged Service for Prometheusでも「Trace Exemplars」として提供され、テール・レイテンシから直接トレースへ遷移できる（Google Cloud Blog）。K3s上の自前Prometheusでも、OpenTelemetry Collector経由で同様の相関機能を組み込める。
K3sクラスタにOpenTelemetry Collectorを組み込む3つの配置パターン
K3s/Kubernetesクラスタへの導入では、OpenTelemetry Collectorをどこに配置するかが設計の肝になる。代表的なパターンは以下の3つに整理される（OpenTelemetry CollectorのKubernetesアーキテクチャ解説）。
Agentパターン（DaemonSet）
各ノードに1つずつCollectorを配置し、ノードローカルのメトリクス・ログ・kubeletの統計情報を収集する。ノード固有のファイルシステムアクセスが必要な収集に向く。
Gatewayパターン（Deployment）
安定したテレメトリ受信エンドポイントを提供する中央集約型パターン。複数のAgentから送られたデータを一箇所に集め、バックエンドへの振り分けやサンプリングを一元管理できる。
Sidecarパターン
アプリケーションPodに専用のCollectorコンテナを同居させる方式。個別設定ができる反面、Pod数に比例してリソース消費も増える。
多くの本番環境では、ノードレベルの収集をAgentで行い中央のGatewayに集約する「Agent-to-Gateway」の2段構成が推奨される。K3sでもこの構成なら、既存のPrometheus Operator/ServiceMonitor構成を壊さず段階的にOTelを導入できる。
サイロ化した可観測性から、相関する可観測性へ
可観測性の課題は「ツールを増やすこと」では解決しない。むしろツールが増えるほどダッシュボード間を往復するコストが膨らむ。重要なのは、メトリクス・ログ・トレースという3つのシグナルを共通のコンテキストで相関させる設計だ。ある求人市場の分析でも、企業が求めているのは個別ツールの操作知識ではなく「システム思考」だと指摘されている。可観測性基盤の設計もこの視点が問われる。
K3sでゼロから可観測性スタックを構築する場合、Prometheus・Grafana・Loki・Tempo(またはJaeger)・OpenTelemetry Collectorを個別にセットアップし、連携設定まで自前で行う必要がある。KuboのようなマネージドK3sサービスなら、Prometheus + Grafanaが標準搭載された状態からスタートでき、OpenTelemetry Collectorを追加するだけで相関分析基盤を構築できる。
まとめ
メトリクス・ログ・トレースを別々のツールで個別に眺めている限り、障害の「本当の原因」には辿り着けない。OpenTelemetryがCNCFで2番目の規模まで成長した背景には、ベンダー中立の標準化と、Exemplarsに代表される「相関させる」設計思想がある。重要なのは闇雲にツールを追加することではなく、既存のPrometheus/ServiceMonitor構成を活かしOpenTelemetry Collectorを段階的に組み込み、メトリクスからトレースへワンクリックで遷移できる基盤を作ることだ。
可観測性スタックの再設計を検討しているなら、Prometheus + Grafanaが標準搭載されたKuboから始めるのも一つの選択肢だ。OpenTelemetry Collectorを追加するだけでサイロ化しない可観測性基盤を構築できる。相談はお問い合わせからいつでも可能だ。