# オブザーバビリティ ## 定義 オブザーバビリティ(observability)は、「外部出力のみからシステムの内部状態を計測する能力」と定義される。外部出力は主にテレメトリデータ（ログ・メトリクス・トレース）であり、分散マイクロサービス系では資源消費量・アプリケーションログ・分散トレースなどが含まれる。モニタリングの代替ではなく**補完**関係にある——モニタリングが事前定義した指標・ログを使って既知の障害仮説を検証する（ブラックボックス視点）のに対し、オブザーバビリティは内部設計・コードの知識を活用して未知の障害を探索する（ホワイトボックス視点）。モニタリングはオブザーバビリティの前提条件であり、両者が連携してはじめて障害検知から根本原因特定まで繋がる。([[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]]) **三本柱（Three Pillars）**とゴールデンシグナルが中核的な枠組みを形成する: | 柱 | 概要 | |----|------| | ログ | 構造化/非構造化テキスト記録。予期しない挙動・障害原因の遡及に使う | | メトリクス | 数値の時系列（タイムスタンプ・名前・ラベル・値）。閾値アラート・容量計画に使う | | トレース | 分散システムをまたぐリクエストの経路記録。ボトルネック特定・因果連鎖の把握に使う | 4 つの SRE ゴールデンシグナル（レイテンシ・トラフィック・エラー・飽和）はこの 3 柱を統合して導出される。([[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]]) ## シグナルの 5 分類（CNCF TAG Observability, 2023） CNCF Whitepaper は従来の「3 本柱（ログ・メトリクス・トレース）」を拡張し、**5 種のシグナル**を定義した（Source: [[@2023__CNCF TAG Observability__Observability Whitepaper]]）: | シグナル | 粒度 | コスト | 主用途 | |---|---|---|---| | メトリクス | 集約数値 | 低 | リアルタイム監視・アラート・トレンド | | ログ | テキストイベント | 中 | デバッグ・監査・根本原因分析 | | トレース | 分散トランザクション木 | 高 | マイクロサービス間因果関係 | | プロファイル | コードレベル実行データ | 中（サンプリング） | 「なぜ遅いか」特定 | | ダンプ | メモリスナップショット | 高 | クラッシュ後詳細診断 | 「万能のシグナルは存在しない。各シグナルはビジネス目標に基づいて選択・組み合わせる」が設計原則。 ## 横断的知見 - **「モニタリング vs オブザーバビリティ」の二項対立から「前提/補完」関係への転換**: Usman ら 2022 のサーベイは両者が代替でなく補完であることを明示し、モニタリングがオブザーバビリティの前提条件であると整理した。一方で、テレメトリのスケーリング問題を扱う Kyoto U サーベイ（[[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]）は「計装→保持→分析」の 3 層フローとして捉えており、どちらの視点から見ても**テレメトリの収集コスト**が共通のボトルネックになる。(Source: [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **統合オブザーバビリティプラットフォームの不在は 2022 年時点でも未解決**: Usman ら 2022 のサーベイが「学術・産業界とも単機能ツールの組み合わせで対応しており、真の統合 OSS ソリューションはほぼ存在しない」と指摘した課題は、2026 年時点の他サーベイ（[[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]]）でも依然としてフラグメントされた状態として扱われている。OpenTelemetry が標準化の中核となりつつあるが、データ処理層の統合は進行中。(Source: [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]], [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]]) - **eBPF が「非侵襲オブザーバビリティ」の実装基盤として収束しつつある**: Usman ら 2022 は ViperProbe・eBPF/XDP を事例として挙げ、アプリ変更なしに L4/L7 レベルのテレメトリを収集できる eBPF のオブザーバビリティへの適合性を指摘した。その後の研究では [[eBPF]] がマイクロサービス([[分散トレーシング]])・GPU インフラ([[GPU観測性]])・LLM 推論([[LLM推論]])の観測基盤として定着しており、「非侵襲・低オーバーヘッドでカーネル/低層からイベントを捕捉する」手法の主流化が複数ソースで確認できる。(Source: [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]], [[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]]) - **シグナル間相関がオブザーバビリティの実用価値を決定する**: CNCF Whitepaper は「各シグナルがサイロ化された状態では 4 つ以上の異なる UI と API を学ぶコストがユーザーにかかる」と指摘し、ターゲットメタデータの統一・Trace ID のログへの付与・Exemplar の利用を相関機構として整理した。この「シグナル横断ナビゲーション」の問題意識は、[[UModel]]（[[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]]）が「4 つのギャップ（死んだトークン・孤立イベント・ツール欠如・サイロ）」として定式化した課題と一致する。(Source: [[@2023__CNCF TAG Observability__Observability Whitepaper]], [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]]) - **実本番 354 件分析が「コンポーネント間・コンポーネント内の階層化オブザーバビリティ」「粒度のオンデマンド切り替え」「データ完全性」を実証的に導出した**: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]](Li+ 2022)は 7 件の障害が「モニタリングデータの欠如」を直接の検知困難要因として列挙したことから 3 カテゴリのオブザーバビリティガイドラインを導いた(Finding G2)。①**データ完全性**: ログ・メトリクス・依存グラフの収集漏れが TTD を長引かせる(MTTD=16.9 分のうちの相当部分が検知不能期間)。②**階層化オブザーバビリティ**: コンポーネント間(サービス間トレース)とコンポーネント内(プロセス/スレッド粒度)の両方を分散トレーシングでカバーする必要があり、どちらかだけでは障害の連鎖が追えない。③**粒度のオンデマンド切り替え**: 通常は粗粒度で収集コストを抑え、障害疑い時には細粒度に切り替える適応的サンプリングを推奨——これは CNCF Whitepaper([[@2023__CNCF TAG Observability__Observability Whitepaper]])が「万能のシグナルは存在しない、ビジネス目標に基づいて選択・組み合わせる」と述べた原則の、障害ライフサイクル時間軸での実装方針と一致する。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) - **メトリクス基数がエコシステムの設計を左右する**: PID ラベルのような高基数次元はコストを爆発させ、CNCF エコシステム（Prometheus/Thanos/Cortex）がスケールメトリクスに集中してきた理由でもある。一方でログ/トレース/プロファイルの専用 DB は CNCF 未収録（2023年時点）であり、エコシステムの非対称性が生まれている。この非対称性は UModel が「オブジェクト中心モデリングで 4 種テレメトリを統合」するアプローチで解消しようとした問題と同型である。(Source: [[@2023__CNCF TAG Observability__Observability Whitepaper]]) - **シグナル横断統合の前提として「単一シグナル内の量的品質」が早くから指摘されていた**: シグナル間相関(CNCF Whitepaper)・MELT 統合(UModel)・観測標準の merge(OpenTelemetry)を扱う横断的議論は、各シグナルが「分析に耐える」前提を暗黙に置いている。これに対し [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]] は分散トレース単体の品質([[トレース品質]])について、OpenTracing 仕様の (a) タイムスタンプ単位非明示(ms と μs が同データセット内で混在)、(b) annotation の任意 key-value 性、(c) testability 欠如、(d) 派生表現(dependency graph・work-flow)生成ツール欠如、を実例で示し、後継 [[OpenTelemetry]] を「merge 努力が主で testability driver の再設計が薄い」と批判した。CNCF Whitepaper・UModel が「シグナルを横に統合する」議論を進める一方で、「シグナル内の量的品質メトリクスを規定する」議論は 2021 年以来、相対的に薄いまま残っている。(Source: [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]], [[@2023__CNCF TAG Observability__Observability Whitepaper]]) ## 未解決の問い - CNCF Whitepaper（2023）の「ギャップ 2: 標準クエリ層の欠如」は 2025〜2026 年時点でどこまで解消されたか？ [[UModel]] の U-SPL は独自 DSL であり業界標準ではない。OpenTelemetry の Query API 標準化は？ - 三本柱（ログ/メトリクス/トレース）の相関付けを単一 API で提供する OSS プラットフォームは 2026 年時点で実現されたか？OpenTelemetry はデータ処理層まで標準化を完了したか？ - エッジ/IIoT 環境のような資源制約デバイスでのオブザーバビリティデータ収集・処理の効率化はどこまで進んだか？ - LLM を使ったオブザーバビリティ強化（AIOps との融合）は、Usman ら 2022 が指摘した「自動根本原因分析」課題をどこまで解決したか？（[[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] などを参照） - セキュリティとコンプライアンス（データ in-flight/at-rest のプライバシー、アクセス制御）はオブザーバビリティプラットフォームの標準仕様に組み込まれたか？ - **シグナル単体の量的品質を評価する標準は OpenTelemetry にどこまで整備されたか**: Bento+ 2021 が「OpenTelemetry は merge 努力が主で testability driver の再設計が薄い」と批判した 2021 年以降、Semantic Conventions・SDK・Specification SIG はトレース/ログ/メトリクスのそれぞれに品質メトリクス(temporal coverage に類するもの)を規定したか。CI/CD に組み込む trace contract testing/lint が本番でどこまで普及したか。([[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]]) ## 関連 - 概念: [[テレメトリ]]・[[分散トレーシング]]・[[トレース品質]]・[[マイクロサービスアーキテクチャ]]・[[AIOps]]・[[根本原因分析]]・[[eBPF]]・[[限定観測可能性]]・[[GPU観測性]] - エンティティ: [[OpenTracing]]・[[OpenTelemetry]]・[[OpenTracing Processor]]・[[Prometheus]]・[[Jaeger]] - ソース: [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]]・[[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]]・[[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]・[[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]] ## 関連エンティティ・ソース - [[CNCF]] / [[TAG Observability]] / [[OpenTelemetry]] / [[Prometheus]] - [[継続的プロファイリング]] — プロファイルシグナルの詳細概念 ## 出典 - [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]] — サーベイ本体、三本柱・ゴールデンシグナル・F*/C* 枠組みの定義 - [[@2023__CNCF TAG Observability__Observability Whitepaper]] — 5 シグナル分類、シグナル相関機構、SLO ベースアラート、エコシステムギャップ - [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]] — §1・§5 OpenTracing 仕様の限界と testability driver の不在批判、§4.2 temporal coverage の導入