# オブザーバビリティ ## 定義 オブザーバビリティ(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]]) ## 子概念 - [[DPDK性能分析]] - [[GenAI オブザーバビリティ]] - [[MLモデル監視]] - [[インバンドネットワークテレメトリ]] - [[オブザーバビリティ駆動開発]] - [[クラウド障害ライフサイクル]] - [[コーディングエージェント評価]] - [[システムズアプローチ]] - [[ゼロコード計装]] - [[ディペンダビリティ]] - [[フィーチャーフラグ]] - [[フィードバック駆動開発]] - [[マイクロサービスアーキテクチャ]] - [[ログ生成]] - [[ログ重複排除]] - [[継続的プロファイリング]] ## シグナルの 5 分類（CNCF TAG Observability, 2023） CNCF Whitepaper は従来の「3 本柱（ログ・メトリクス・トレース）」を拡張し、**5 種のシグナル**を定義した（Source: [[@2023__CNCF TAG Observability__Observability Whitepaper]]）: | シグナル | 粒度 | コスト | 主用途 | |---|---|---|---| | メトリクス | 集約数値 | 低 | リアルタイム監視・アラート・トレンド | | ログ | テキストイベント | 中 | デバッグ・監査・根本原因分析 | | トレース | 分散トランザクション木 | 高 | マイクロサービス間因果関係 | | プロファイル | コードレベル実行データ | 中（サンプリング） | 「なぜ遅いか」特定 | | ダンプ | メモリスナップショット | 高 | クラッシュ後詳細診断 | 「万能のシグナルは存在しない。各シグナルはビジネス目標に基づいて選択・組み合わせる」が設計原則。 ## Observability 1.0 と 2.0(Charity Majors, 2024) [[Honeycomb.io]] 共同創業者 [[Charity Majors]] は2024年、モニタリングの再ブランディングと化した「オブザーバビリティ」を技術用語で再度差別化するため、この区分を提唱した(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 3 The Origins of Observability in Software]]): | | Observability 1.0 | Observability 2.0 | |---|---|---| | ストレージ | シグナル種別ごとに別ツール・別ストレージ(メトリクス→時系列DB、ログ→ログ集約器、トレース→トレーシングツール…) | 単一の統合ストレージへ構造化テレメトリを送る | | 相関 | 柱をまたぐ相関は手作業で事前定義・維持する | 関係性を保持したデータに対し後から相関を問い合わせる | | コスト | 同じデータを何度も課金して保存する | 一度だけ課金して保存する | Majors 自身は「1.0 対 2.0」という番号付けを「ありふれた技術的常套句」と自嘲しつつ、2026年初頭に Hazel Weakly がデータレイクハウス的構成を「Observability 3.0」と呼ぶ提案を出すなど、番号付けの軍拡競争が続いている現状にも言及する。この区分は、2016年の Honeycomb 創業時に Majors と [[Christine Yen]] が制御理論に着想を得て導出した6つの機能要件(高次元・高カーディナリティ・生イベントの読み取り時集約・ズームイン/アウト・探索的UI・秒単位クエリ)の実装形態を、10年越しに再整理したものといえる。 ## 横断的知見 - **カーネルバイパス環境では、オブザーバビリティの焦点が「外部出力」からユーザー空間内部の状態へ移る**: DPDK はカーネル境界に依存する従来の監視経路を迂回するため、native tracer の CTF、State History Tree、Trace Compass の同期ビューを使って lcore・service・poll・mempool を再構築する必要がある。これは三本柱の抽象的な信号分類を、DPDK の実行状態と資源所有へ具体化した例である。さらに RX throughput 低下から poll 分布、allocation rate、mempool 枯渇へ進むケーススタディは、低レベルイベントをドメイン固有の診断メトリクスへ変換して初めて根本原因分析に使えることを示す。(Source: [[@2026__ICPE__A Transparent and Efficient Performance Analysis Approach to Enhance DPDK Observability]], [[@2023__CNCF TAG Observability__Observability Whitepaper]]) - **「モニタリング vs オブザーバビリティ」の二項対立から「前提/補完」関係への転換**: Usman ら 2022 のサーベイは両者が代替でなく補完であることを明示し、モニタリングがオブザーバビリティの前提条件であると整理した。一方で、テレメトリのスケーリング問題を扱う Kyoto U サーベイ（[[Scaling Telemetry Workloads in Cloud Applications]]）は「計装→保持→分析」の 3 層フローとして捉えており、どちらの視点から見ても**テレメトリの収集コスト**が共通のボトルネックになる。(Source: [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]], [[Scaling Telemetry Workloads in Cloud Applications]]) - **統合オブザーバビリティプラットフォームの不在は 2022 年時点でも未解決**: Usman ら 2022 のサーベイが「学術・産業界とも単機能ツールの組み合わせで対応しており、真の統合 OSS ソリューションはほぼ存在しない」と指摘した課題は、2026 年時点の他サーベイ（[[Anomaly detection and root-cause identification in microservices]]）でも依然としてフラグメントされた状態として扱われている。OpenTelemetry が標準化の中核となりつつあるが、データ処理層の統合は進行中。(Source: [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]], [[Anomaly detection and root-cause identification in microservices]]) - **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]]) - **「モニタリングからオブザーバビリティへ」の実装移行コストは過大評価されていた**: [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices|Smith SREcon22]] は、Prometheus ベースのアプリケーションメトリクスからコンテキスト付き分散トレーシング（Honeycomb + OpenTelemetry Java エージェント）への移行に 6 か月以上躊躇したが、実際の自動計装には**4 時間**しかかからなかったと報告した。Usman ら 2022 が「統合 OSS ソリューションはほぼ存在しない」と指摘した 2022 年時点で、商用プラットフォーム（Honeycomb）+ 標準計装（OpenTelemetry）の組み合わせが小規模組織（約 100 名、数サービス）では極めて低コストに機能した事例である。この「移行コストの認知バイアス」は技術的課題ではなく心理的障壁であり、SRE Book/Workbook の導入ガイドが「how to migrate」より「when to start」を強調すべき根拠になる。また、移行後に開発者がカスタム属性を自発的に追加し始めた事実は、低い参入障壁がツール採用率の正のフィードバックループを生むことを示唆する。(Source: [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]], [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]]) - **GenAI ワークロードがオブザーバビリティの観測対象を「アプリケーション API の内側」に深層化する**: OpenTelemetry セマンティック規約が LLM 呼び出しチェーン（`invoke_agent` → `chat` / `execute_tool`）のスパン階層を標準化し、トークン消費・LLM レイテンシ・プロンプト/補完内容を記録可能にした（Source: [[@2026__OTelBlog__GenAI Observability with OpenTelemetry]]）。従来の三本柱（ログ・メトリクス・トレース）が HTTP リクエスト/DB クエリ/メッセージキューを観測対象としてきたのに対し、GenAI オブザーバビリティはモデル呼び出しの内部構造を対象とする。CNCF Whitepaper（2023）が「万能のシグナルは存在しない」と述べた設計原則の延長上にあるが、シグナルの種類だけでなく**観測の粒度そのもの**が新たなレイヤーに拡張されている。（Source: [[@2023__CNCF TAG Observability__Observability Whitepaper]]、[[@2026__OTelBlog__GenAI Observability with OpenTelemetry]]） - **日本コミュニティではトレースが 93% で最多シグナルであり、メトリクス首位の国際パターンと顕著に乖離する**: OpenTelemetry 日本コミュニティ調査（Source: [[@2026__OTelBlog__Japanese Community Survey]]）では、トレース 93%・メトリクス 71%・ログ 60% の順で、CNCF Whitepaper や Collector フォローアップ調査（Source: [[@2026__OTelBlog__OTel Collector Follow-up Survey]]）で示されたメトリクス中心の国際パターンと異なる。この乖離の要因は調査では特定されていないが、日本の OTel 採用が Java・Go 中心（言語エージェント自動計装との親和性が高い）であること、回答者の 22.94% が SRE であること、NPS +49 の成熟コミュニティであることが背景に推測される。（Source: [[@2026__OTelBlog__Japanese Community Survey]]、[[@2026__OTelBlog__OTel Collector Follow-up Survey]]） - **FDD は「開発者向けオブザーバビリティ活用」の 2015 年時点の体系化である**: [[フィードバック駆動開発]](FDD, Cito+ 2015)は、APM ツールが生成する運用データ(応答時間・コスト・クリックストリーム)を開発者の IDE に直接統合し、コードアーティファクト(メソッド・ループ・サービス呼び出し)に紐づけるビジョンを提唱した。これは「オブザーバビリティデータはオペレーター向け」という 2015 年時点の状況を「開発者向けにも活用する」方向に転換しようとした先駆的取り組みである。Usman ら 2022 のサーベイが「統合 OSS ソリューションはほぼ存在しない」と指摘した状況と対応しており、FDD は 10 年後の OpenTelemetry コード属性・継続的プロファイリング製品(Polar Signals, Pyroscope 等)として部分的に実現された。「本番フィードバックの開発フロー統合」という方向性は 2015 → 2025 の 10 年をかけて徐々に標準化されつつある。(Source: [[@2015__Onward!__Runtime Metric Meets Developer - Building Better Cloud Applications using Feedback]], [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]]) - **オブザーバビリティは「人間が作るもの」から「コーディングエージェントが生成すべきもの」へ対象を広げつつあり、生成側の能力そのものが新たなギャップとして浮上した**: 本 wiki のオブザーバビリティ議論はこれまで一貫して「人間/組織がどう設計・運用するか」を扱ってきたが、[[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]] は評価対象を「コーディングエージェントが生成するコードのオブザーバビリティ」自体へ転換する。18 リポジトリ・1,223 インスタンスのソースレベル復元実験では、エージェントは人間記述のオブザーバビリティを配置(Position F1: blind 0.551〜few-shot 0.594)は比較的よく再現するが、診断意味論(KeyBag F1: blind 0.357〜few-shot 0.383)の再現は一貫して弱い。この「どこに計装するかは分かるが何を記録すべきかが分からない」という非対称性は、三本柱(ログ・メトリクス・トレース)やゴールデンシグナルのような**シグナルの種類・配置の設計論**では捉えられない、**シグナルの中身(診断意味論)の生成能力**という新しい問題次元を提起する。(Source: [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]]) - **明示的指示が「量」を増やすが「質」を下げる Quantity-over-Quality 現象は、CNCF Whitepaper の「万能のシグナルは存在しない」原則の生成側での反例になる**: observability-hinted プロンプト(明示的にオブザーバビリティ改善を指示)は blind プロンプトと比べ生成文数を 2.1→4.9 文/インスタンス、KeyBag トークン数を 11.5→22.9 へ倍増させるが、KeyBag F1 は 0.357→0.260、Position F1 は 0.551→0.505 とむしろ低下する。CNCF Whitepaper がシグナルの「選択と組み合わせ」を設計原則としたのに対し、生成モデルは明示的指示に対して「選択」でなく「網羅的な過剰生成」で応答し、精度を犠牲にする。これは人間エンジニアの計装判断とコーディングエージェントの計装判断が異なるバイアス構造を持つことを示唆し、[[ログ生成]] が指摘する「LLM は難所を再配置するだけ」というメタパターンの一例でもある。(Source: [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]]) - **「ログは大量にあるが障害シグナルを含まない」現象を、実行時オブザーバビリティの保守的指標(FSR)が定量化した**: 200 個の agent 生成マイクロサービスを Kubernetes 上にデプロイし 13 種の障害を注入した実行時実験(1,615 件)では、生成システムはログを豊富に出力するにもかかわらず Fault Signals Rate は 4.95〜13.99% にとどまる。これは「ログの量」でなく「障害固有の明示的意味論を含むか」を測る保守的な定義であり、CNCF Whitepaper が指摘した「シグナルのサイロ化」や UModel の「死んだトークン・孤立イベント」問題とは異なる次元の欠落——**シグナル自体は存在するが、意味論的に空虚**——を可視化した。(Source: [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]]) - **OSレベルの伝統的ツール分類(2020年)とCNCFの5シグナル分類(2023年)は、粒度と観測層で異なる次元をとる**: 『詳解 システム・パフォーマンス 第2版』4章は Linux 可観測性ツールを「システム全体/プロセスごと」×「固定カウンタ/イベントベース」の2軸4象限(カウンタ・プロファイリング・トレーシング・モニタリング)で分類する(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]])。CNCF Whitepaper の5シグナル分類(メトリクス・ログ・トレース・プロファイル・ダンプ)と対応させると、Gregg の「固定カウンタ」はメトリクスに、「プロファイリング」はプロファイルに、「トレーシング」はログ・トレースの一部にそれぞれ近い。ただし Gregg の分類は OS カーネル層のツール(vmstat・perf・bpftrace 等)を対象とし、CNCF の分類はアプリケーション層のテレメトリシグナルを対象とするため、同じ語彙(トレーシング/トレース、プロファイリング/プロファイル)が指す抽象度が異なる点に注意が要る。両者を接続する共通の下部構造は、Gregg が詳述する `/proc`・`/sys`・トレースポイント・kprobe・uprobe・USDT・PMC のような OS 情報ソースであり、CNCF の各シグナルは最終的にこれらのカーネル/ランタイム情報源から供給される。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]], [[@2023__CNCF TAG Observability__Observability Whitepaper]]) - **「外部出力のみから内部状態を計測する能力」という分散システム的定義と、「システムに摂動を与えない」という運用的境界線は、同じ語を異なる軸で切り分ける**: Usman ら 2022 のサーベイはオブザーバビリティを「外部出力のみからシステムの内部状態を計測する能力」とデータソース(ログ・メトリクス・トレース)の観点で定義する(Source: [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]])。これに対し Gregg(2023、§1.7〜§1.8)は、可観測性ツール(カウンタ・プロファイリング・トレーシングを使うツール)と実験(ベンチマーキング)ツールを「システムの状態を変えるかどうか」という摂動の有無だけで明確に線引きし、本番環境ではまず可観測性ツールを使うべきだと述べる。前者はデータの出所を軸にした分類、後者はシステムへの副作用を軸にした分類であり、両者は独立した境界線でありながら実務上は強く相関する(摂動を与えない手段の多くは外部出力の観察に限られる)。この2軸を明示的に区別しないまま「オブザーバビリティ」という語を使うと、ベンチマークツール由来のデータをオブザーバビリティデータと誤って同一視するおそれがある。(Source: [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]], [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 1 イントロダクション]]) - **「外部出力のみから内部状態を計測する能力」という分散システム的定義は、1960年のKálmánの制御理論的定義への直接の先祖返りである**: Usman ら 2022([[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]])が採る「外部出力のみからシステムの内部状態を計測する能力」という定義は、[[Rudolf E. Kálmán]] が1960年に制御理論の論文で与えた原義——計測可能な出力だけから完全な内部状態を推測できるかを問い、可制御性(controllability)と双対をなす——とほぼ同型であり、分散システム研究のオブザーバビリティ定義が制御理論の定義を(ソフトウェアには存在しない可制御性の部分を除いて)ほぼそのまま継承していることを示す。(Source: [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]], [[@2026__OReilly__Observability Engineering 2E - Chapter 1 What Is Observability?]]) - **オブザーバビリティを「[[ディペンダビリティ]] の第7属性」として位置づける主張が現れ、三本柱/CNCF 5シグナルのような「シグナル分類」の議論とは別の上位レイヤーの整理を提示する**: 本ページの既存議論(三本柱・CNCF 5シグナル・Gregg の2軸4象限)はいずれもオブザーバビリティを実現する**シグナルやツールの分類**を扱う。これに対し『Observability Engineering』第2版第1章は、Jean-Claude Laprie の1995年ディペンダビリティ6属性(可用性・信頼性・保守性・安全性・機密性・完全性)フレームワークに「任意のシステム状態を理解・デバッグできる能力」としてのオブザーバビリティを第7の属性として加えるべきだと主張し、オブザーバビリティを**ツール/シグナルの分類問題ではなくソフトウェアの性質そのもの**として再定義する。この立場は、モニタリングが「稼働/停止」の二値判定に、より高度なモニタリングが「どこで」遅いかの特定に有効だが「なぜ」かは説明できないという限界の指摘と対になっている。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 1 What Is Observability?]], [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]]) - **「オブザーバビリティは開発者のためのツール、モニタリングはインフラ運用のためのツール」という創業者の当事者的主張は、CNCF Whitepaper のシグナル分類論とは異なる「対象読者」の軸で三本柱批判を行う**: Majors は本章で「三本柱・インフラモニタリング型ツールは、モニタリングと同じ言葉を使いまわしているだけで開発者のニーズには応えていない」と主張し、モニタリングを運用チーム向け、オブザーバビリティを開発者がコードを本番で理解するためのツールと明確に切り分ける(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 3 The Origins of Observability in Software]])。CNCF Whitepaper(2023)の5シグナル分類は「どのシグナルを選ぶか」というデータ設計の軸で三本柱を拡張したが、「誰のためのツールか」という組織的な対象読者の軸には触れていない。両者を重ねると、オブザーバビリティの意味の希薄化は単なる技術的な混同ではなく、シグナルの種類が同じでも受益者(開発者かオペレータか)によって設計要件(探索的UI・秒単位クエリの必要性など)が変わるという組織論的な混同でもあることが分かる。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 3 The Origins of Observability in Software]], [[@2023__CNCF TAG Observability__Observability Whitepaper]]) - **AIがオブザーバビリティを変える力として、データモデルの経済(統合ストレージへの圧力)とシグナル意味論の深化(LLM呼び出しの計装)という2つの異なる経路が並行して働いている**: Majors は Observability 2.0(単一ストレージ・一度だけの課金)への移行をコストと AI が後押ししていると主張し、AI エージェントが大量のコンテキストを要求し非決定性の計装・観測を必須化することを理由に挙げる(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 3 The Origins of Observability in Software]])。一方 OpenTelemetry セマンティック規約は LLM 呼び出しチェーン(`invoke_agent` → `chat` / `execute_tool`)のスパン階層を標準化し、シグナルの種類ではなく観測の粒度そのものをモデル内部へ深層化させている(Source: [[@2026__OTelBlog__GenAI Observability with OpenTelemetry]])。前者は「テレメトリの保存・課金モデル」という経済的圧力、後者は「何を計装すべきか」という意味論的深化であり、AI は異なる2つの経路からオブザーバビリティの実装を同時に押し広げている。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 3 The Origins of Observability in Software]], [[@2026__OTelBlog__GenAI Observability with OpenTelemetry]]) - **三本柱モデル/統合ストレージモデルという2世代のツール系譜は、Observability 1.0/2.0(Majors 2024)のストレージアーキテクチャの区分を「誰の学習を支えるか」という組織的目的の軸で再解釈したものである**: 『Observability Engineering』第2版第25章は、三本柱モデル(メトリクス・ログ・トレースを個別ツールで扱う)を運用アウトカム(インフラ可視化・混沌としたインシデント対応)向けの成熟したツール系譜、統合ストレージモデルをデリバリー速度・顧客体験理解という開発者学習向けのツール系譜として対比する(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 25 The Observability Landscape Through a Systems Lens]])。この対比は第3章の Observability 1.0(シグナル種別ごとに別ストレージ)/2.0(単一の統合ストレージ)というストレージアーキテクチャの区分(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 3 The Origins of Observability in Software]])と技術的に同型だが、第25章は「開発者ループ(developer loop)は merge で止まり、運用ループ(operational loop)は障害発生時に始まる」というフィードバックループの欠落を選定基準の一次軸に置く点で異なる。つまり「ストレージが統合されているか」という技術的軸と「開発者の学習を支えるように設計されているか」という組織的軸は、同じ2世代区分を異なる角度から説明する双対関係にある。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 25 The Observability Landscape Through a Systems Lens]], [[@2026__OReilly__Observability Engineering 2E - Chapter 3 The Origins of Observability in Software]]) - **オブザーバビリティは「シグナルの分類」から「本番検証プラクティス群の前提条件(キーストーン)」へと役割が拡張される**: 本ページのこれまでの議論(三本柱・CNCF 5シグナル・Observability 1.0/2.0)はいずれもオブザーバビリティを**データ・ツールの分類問題**として扱う。これに対し『Observability Engineering』第2版第2章は、オブザーバビリティを「Practice 0」と位置づけ、[[フィーチャーフラグ]]によるデプロイ/リリース分離やプログレッシブデリバリー([[カナリアテスト]]参照)を含む本番検証の一連の実践が、高カーディナリティ・広いコンテキストを持つ構造化イベントの上に構築されて初めて機能する「フライホイール」を成すと主張する。三本柱型の事前集約メトリクスや相関しないログの上にこれらの実践を導入しても平凡な結果しか生まれないとされ、これは Smith SREcon22(Source: [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]])が報告した「モニタリングからオブザーバビリティへの移行コストの過小さ」の裏返しとして、オブザーバビリティ自体の整備が後続の全ての本番プラクティスの投資対効果を左右するという、より強い依存関係を示す。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]], [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]]) - **オブザーバビリティとデバッグ/プロファイリングの境界線は、Gregg の摂動の有無による2軸4象限分類とは別の「観測の粒度」という軸で引かれる**: 『詳解 システム・パフォーマンス 第2版』4章はカウンタ・プロファイリング・トレーシング・モニタリングを「システム全体/プロセスごと」×「固定カウンタ/イベントベース」で分類し(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]])、いずれもシステムの状態を変えない可観測性ツールとして扱う。これに対し『Observability Engineering』第2版9章は、オブザーバビリティを「システム」レベル(どのコンポーネント・依存先・ユーザーセグメントで問題が起きているか絞り込む望遠鏡)に限定し、そこから先の「関数」レベルのコード深掘りはデバッガ(GDB)や新世代プロファイラという別カテゴリの道具に委ねるべきだと主張する。行レベルの詳細度をオブザーバビリティ系に出力するとストレージ・処理コストが破綻するというコスト面の理由が明示される点で、Gregg の分類が扱わない「なぜこの境界線を引くべきか」という運用上の根拠を補う。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 9 Observability-Driven Development]], [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]]) - **Dickersonの信頼性の階層構造は監視/オブザーバビリティを技術的なシグナル分類ではなく信頼性ピラミッドの土台として位置づけ、組織論的な役割(信頼できる議論の共通言語、コンウェイの法則が写し出す組織の鏡)を強調する**: 本ページの既存議論(三本柱・CNCF 5シグナル・Observability 1.0/2.0)はいずれもオブザーバビリティを実現する**シグナルやツールの分類**を扱う。これに対し『SREをはじめよう』14章は、監視/オブザーバビリティを「他の全階層(インシデントレスポンス・ポストモーテム・テスト/リリース等)が積み上がる土台」と位置づけ、その価値を(1)変更が信頼性に与えた影響を判断するナビゲーション情報源、(2)信頼性についての客観的な議論を可能にする「真実の情報源」、(3)SLI/SLOの実践基盤、(4)監視/アラートの乱雑さが組織文化を映す「(意図しない)鏡」——コンウェイの法則が監視システムの構造にも作用する——という4つの組織論的な役割で説明する。CNCF Whitepaper・Observability Engineering第2版が「どのシグナルを選ぶか」「誰のためのツールか」という設計論の軸で三本柱を拡張してきたのに対し、Dickersonの階層構造は「監視システムが固まっていなければ他の階層に進めない」という**投資の順序**の軸を追加する。(Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 14 Dickersonの信頼性の階層構造（良い出発点）]] §14.1.1) - **「監視 対 可観測性は補完関係」という一般的整理を、『信頼性の高い機械学習』9 章は ML システムに特化した 3 層モデルとして具体化する**: Usman ら 2022([[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]])は監視を可観測性の前提条件とする補完関係を一般的に述べるが、対象は分散マイクロサービス一般でありモデル固有の関心事は扱わない。これに対し [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 9 モデルの監視と可観測性]] §9.1.1(図9-1)は、ソフトウェアアプリケーション監視(評価指標・ログ・トレーシング)→データアプリケーション監視(データの鮮度・スキーマ・分布)→ML 可観測性(ベースラインとのドリフト・特徴量重要度・公平性・説明可能性・ビジネスインパクト)という 3 層モデルを提示し、下位層に行くほど取得すべき対象と必要な可観測性の複雑さが増すと整理する。これは Usman らの一般的な「監視は可観測性の前提」という関係を、ML システム特有の積み上げ構造(ソフトウェア層→データ層→モデル層)として具体化したものであり、CNCF Whitepaper の「万能のシグナルは存在しない」原則と同様に、ML ドメインでは可観測性の対象がシグナルの種類だけでなくシステムのレイヤーに沿っても多層化することを示す。(Source: [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]], [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 9 モデルの監視と可観測性]] §9.1.1) - **分散トレーシングインフラ(Dapper系譜)の価値は「診断」だけでなく「実験選択の自動化のための学習」にも及ぶという主張が、Safety-IIという別分野の概念を根拠に示された**: 本ページはこれまでコールグラフトレースの価値をテールレイテンシ診断(Dapperの動機)や開発者ループのフライホイール(Practice 0、既出)という角度で蓄積してきたが、『カオスエンジニアリング』12章(著者[[Peter Alvaro]]、LDFIの提唱者)は同じDapper系譜のトレースインフラ(Dapper→Zipkin→Jaeger→OpenTracing→2019年以降はOpenTelemetryへ標準化)について、SRE・開発者の典型的な用途が「何がうまくいかなかったかの診断」や「人間による可視化」という狭いユースケースに偏りがちであると指摘し、レジリエンスエンジニアリングのSafety-II概念(Hollnagelを引用)を根拠に「何がうまくいったかの学習」への価値の転換を主張する——成功した実行のコールグラフの蓄積は、システムがどの故障をどう許容したかという冗長性の構造を明らかにし、カオス実験の選択・優先順位づけを可能にする。これは『Observability Engineering』第2版がPractice 0として位置づける「本番検証プラクティス群の土台」という一般論(既出)を、「カオス実験の自動選択」という具体的な下流用途で裏付ける事例である。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 12 実験の選択に関する課題（と、その解決策）]] §12.2, §12.2.1, [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]]) - **マイクロサービス異常検知サーベイのデータ収集方法分類が三本柱にとどまる理由は、対象文献(2012〜2025年)のCNCF 5シグナル分類(2023年公開)への遅延が原因か、それとも異常検知という応用領域自体がプロファイル・ダンプを本質的に必要としないためか**: 両者を切り分けるには、CNCF Whitepaper公開後(2023年以降)に採択された文献に限定してプロファイル・ダンプベースの異常検知手法が登場しているかを確認する必要があるが、サーベイ§4.2の記述からはこの時系列的な切り分けはできない。(Source: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.2 Data collection methods]], [[@2023__CNCF TAG Observability__Observability Whitepaper]]) - **「オブザーバビリティを他の必須特性と同列に置く」という主張は、2022年時点でCNCF Whitepaperが暗黙に扱っていたシグナル分類論と、2026年に明示された「ディペンダビリティの第7属性」論の中間に位置する、独立した第三の定式化である**: 本ページはこれまで、CNCF Whitepaper(2023)の5シグナル分類(本ページ「定義」節)と、『Observability Engineering』第2版第1章(2026)が主張する「ディペンダビリティの第7属性」論(既出)を、オブザーバビリティを一段上のカテゴリへ位置づけ直す議論として記録してきた。第11章「ネットワーク管理は今やクールな仕事だ」§11.5は、Larry Petersonが2022年に「オブザーバビリティを『優れたシステムが備えるべき〇〇ビリティの一つ』として、規模拡張性・信頼性・可用性・安全性・利便性と同列に論じるべきだ」と主張していたことを示し、この立場は『Observability Engineering』のディペンダビリティ第7属性論に4年先行する独立した定式化である。両者は「オブザーバビリティを単なるツール・シグナルの分類問題ではなくシステムの性質として扱うべきだ」という結論で一致するが、根拠が異なる——ディペンダビリティ第7属性論はLaprie 1995の学術的タクソノミーへの追加という体系的根拠を持つのに対し、第11章の主張は「なぜオブザーバビリティだけが監視より優れていると宣伝されるのか判然としない」という業界の誇大広告への違和感から出発する実務者の直観である。異なる時期・異なる根拠から同じ結論に到達したことは、この定式化の妥当性を補強する。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.5, [[@2026__OReilly__Observability Engineering 2E - Chapter 1 What Is Observability?]]) - **第11章が提案する「INT(Inband Network Telemetry)を第四の柱に加える」という発想は、CNCF Whitepaperの5シグナル拡張と同じ運動の、ネットワークデータプレーンという異なる層での再現である**: 本ページはCNCF Whitepaper(2023)が三本柱(ログ・メトリクス・トレース)にプロファイル・ダンプを加えて5シグナルへ拡張したこと、GenAIワークロードがLLM呼び出しチェーンという新レイヤーへ観測粒度を深層化させたことを記録してきた(既出)。第11章§11.5は、メトリクス・ログ・トレースという「一般的な三種のテレメトリ」に加え、「ネットワークのデータプレーンにおけるフローレベルの状態をINTを用いてクエリする能力」を第四の要素として個人的に加えたいと述べる。これはCNCF・GenAIの拡張が「シグナルの種類」や「観測の粒度」を一般的なアプリケーション層で広げたのに対し、第11章の拡張はネットワークのデータプレーンという特定ドメインの状態を対象とする点で、[[インバンドネットワークテレメトリ]]・[[ネットワーク監視]]が扱う物理層・L3層のテレメトリ議論とも接続する——オブザーバビリティのシグナル拡張運動が、アプリケーション層(GenAI)とネットワーク層(INT)の両極で独立に進行していることが分かる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.5, [[@2023__CNCF TAG Observability__Observability Whitepaper]]) - **「開発者と運用者のインセンティブの不整合」という第11章の指摘は、『Observability Engineering』第25章が示す開発者ループ/運用ループの分離を、より直接的な当事者の言葉で先取りしていた**: 本ページは『Observability Engineering』第2版第25章が、三本柱モデル(運用アウトカム向け)と統合ストレージモデル(開発者学習向け)を「開発者ループはmergeで止まり、運用ループは障害発生時に始まる」というフィードバックループの欠落で対比したことを記録している(既出)。第11章§11.5の「インセンティブとの整合性」という節は、これと同じ分断をより直接的な当事者視点で描く——「開発者は『自分のマシンで動く』段階をクリアすると自分が開発している構成要素を正しいと思い込みやすく、エンドツーエンドにおける運用時の挙動にはほとんど関心がない」ため、「開発と運用とではインセンティブが揃っておらず、DevOpsという物語には亀裂がある」と明言する。第25章が2つのツール系譜という技術的・組織的な軸で分析するのに対し、第11章はこの分断を「トラブルシューティングという行為がどうしようもなく属人的で文脈に強く依存する泥臭いプロセスである」という認識論的な困難(原因を探るクエリを知るには深い専門知識を要する)にまで掘り下げ、開発者に画一的なオブザーバビリティフレームワークの採用を説得することの困難さの根としている。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.5, [[@2026__OReilly__Observability Engineering 2E - Chapter 25 The Observability Landscape Through a Systems Lens]]) - **サービスメッシュを「開発者のベストエフォートに頼らないオブザーバビリティ」の手段とする第11章の主張は、eBPFの非侵襲オブザーバビリティ収束という既存の横断的知見に、サービスメッシュという別の非侵襲経路を加える**: 本ページは、eBPFが「非侵襲・低オーバーヘッドでカーネル/低層からイベントを捕捉する」手法としてマイクロサービス・GPU・LLM推論の観測基盤に収束しつつあることを記録してきた(既出)。第11章§11.5は、開発者のベストエフォート(アプリケーションコードへの計装)に頼らない選択肢として、Istio・Tetragonのようなサービスメッシュを挙げる——「サービスメッシュの最大の強みは、アプリケーションの直近に配置されるので、そこを出入りするトラフィックを詳細に把握できる点にあり、さらに重要な点として、その可視性を得るためにアプリケーションに追加のコードを書く必要がない」。eBPFがカーネルレベルでアプリケーションコードを介さずに計装するのに対し、サービスメッシュはネットワークプロキシ層でアプリケーションコードを介さずに計装する——両者は捕捉するレイヤーが異なる(カーネル 対 ネットワークプロキシ)が、「アプリケーション開発者に計装を書かせない」という同じ設計原理を共有する。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.5) - **博士論文はオブザーバビリティを「テレメトリ管理のフレームワーク」と位置づけ、`Observability Engineering`第2版の「ディペンダビリティの第7属性」論とは逆方向の抽象化を取る**: 第2章§2.3 は「近年、オブザーバビリティは大規模テレメトリデータを管理するフレームワークとして産業界で注目を集めている」と述べ、テレメトリを基盤データ、オブザーバビリティをその上に立つ管理枠組みとして明確に位置づける。定義自体はUsmanら2022・Kálmán起源の「外部出力のみから内部状態を計測する能力」と同型だが(既出)、力点が異なる——博士論文はオブザーバビリティを**データ管理問題の解法**として道具的に扱うのに対し、`Observability Engineering`第2版第1章はオブザーバビリティを**ソフトウェアそのものの性質**(ディペンダビリティの第7属性)として道具の位置から引き上げる(既出)。同じ制御理論由来の定義を共有しながら、2025年の博士論文(システム研究の伝統)は「テレメトリの上位フレームワーク」という工学的・道具的な抽象化を取り、2026年の実務書は「ソフトウェアの属性」というより存在論的な抽象化を取る——両者は矛盾しないが、同じ語がジャンルによって異なる階層に置かれることを示す。(Source: [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 2 Background]] §2.3, [[@2026__OReilly__Observability Engineering 2E - Chapter 1 What Is Observability?]]) - **マイクロサービス異常検知サーベイのデータ収集方法分類(ログ/分散トレーシング/監視)は、CNCF Whitepaperの5シグナル分類のうち「プロファイル」「ダンプ」を欠いた古典的な三本柱に収束しており、異常検知という実用文脈では拡張シグナルがまだ定着していないことを示唆する**: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.2 Data collection methods]](§4.2)は、マイクロサービスの異常検知手法をログベース・分散トレーシングベース・監視ベース(メトリクスベース)の3種類に分類する。これはCNCF Whitepaper(2023)の5シグナル分類(メトリクス・ログ・トレース・プロファイル・ダンプ、本ページ「定義」節)のうち最初の3つ(三本柱)とほぼ一致するが、プロファイル・ダンプへの言及はない。同サーベイは各データ収集方法固有の限界も指摘する——ログ単体では異常な動作の全てを捕捉できず(§4.2.1)、トレースは大規模になるほど保存・処理コストが増大し(§4.2.2)、メトリクスはノイズと変動性への対応として複数メトリクスの相関付けが必要になる(§4.2.3)——という記述は、CNCF Whitepaperの「万能のシグナルは存在しない」原則(本ページ既出)を、マイクロサービス異常検知という具体的タスクの制約条件として裏づける。5シグナルへの拡張が2023年時点で提案されていたにもかかわらず、2012〜2025年の学術文献(2026年公表の当該サーベイが対象とする期間)では依然として古典的な三本柱の枠内でデータ収集方法が議論されている点は、シグナル分類の理論的拡張と実証研究の実践との間に時間差があることを示す。(Source: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.2 Data collection methods]], [[@2023__CNCF TAG Observability__Observability Whitepaper]]) - 計装とサンプリングは収集可能なデータ・正確性・オーバーヘッドの観点でトレードオフの関係にあり、性能変化の検知(measurement のexactness、精度accuracyとは異なる軸)を目的とするなら、少数メソッドへの事前選択ができない限りサンプリングの方が実行可能である(Source: [[@2026__ICPE__Benchmarking Change Detection Exactness and Overhead of Instrumentation and Sampling]]) ## 未解決の問い - 第11章が提案する「INTを第四の柱に加える」という個人的見解は、CNCF Whitepaperの5シグナル分類やOpenTelemetryのセマンティック規約にどこまで反映されたか。ネットワークデータプレーンのフローレベル状態を標準的なテレメトリシグナルとして扱う標準化の動きは2026年時点でどこまで進んだか。 - 第11章は「トラブルシューティングという行為の属人性・文脈依存性」を画一的なオブザーバビリティフレームワーク導入の障壁として挙げるが、この属人的な専門知識をLLMエージェントが代替・支援する動き([[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]]等、既出)は、この障壁をどこまで解消するか。 - DPDK native tracing の CTF、Linux kernel trace、アプリケーションイベントを同じ時計とデータモデルで相関させるとき、欠損・粒度・収集オーバーヘッドを含めたオブザーバビリティの品質をどのように評価するか。(Source: [[@2026__ICPE__A Transparent and Efficient Performance Analysis Approach to Enhance DPDK Observability]]) - **Dickersonの信頼性の階層構造が「監視/オブザーバビリティが固まってから次の階層に進む」と主張する順序は、実証的にどこまで検証されているか**: 監視への投資が後続層(インシデントレスポンス・ポストモーテム等)の成熟度をどの程度予測するかを定量的に検証した研究はあるか。(Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 14 Dickersonの信頼性の階層構造（良い出発点）]]) - **Majors が2024年に提唱した Observability 1.0/2.0 の区分は、2026年時点でどの程度業界に浸透したか**: 本章は「世界はゆっくりと、しかし確実に統合モデルへ向かっている」という著者個人の見解を述べるにとどまり、実際の市場シェアや移行率のデータは示されない。OpenTelemetry 日本コミュニティ調査(Source: [[@2026__OTelBlog__Japanese Community Survey]])のようなアンケートベースの実測データと突き合わせて検証できるか。 - 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]]) - **コーディングエージェントの「診断意味論の生成能力」不足は、訓練データの性質に起因するのか、実行時フィードバックの欠如に起因するのか**: [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]] は 2 つの仮説(オブザーバビリティが訓練データで独立した目的として表現されにくい/エージェントが静的ソースコードのみから学習し実行時挙動から学習しない)を提示するが未検証のままである。ランタイムフィードバックや障害伝播シミュレーションを生成プロセスに統合すると、KeyBag F1・FSR はどこまで改善するか。(Source: [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]]) - **オブザーバビリティを「ディペンダビリティの第7属性」とする2026年の提案は、ソフトウェア工学の標準的なディペンダビリティ研究(Avizienis 2004 の6+2属性タクソノミー)にどこまで浸透・整合しているか**: [[ディペンダビリティ]] ページが整理する Avizienis 2004 の属性一覧(可用性・信頼性・安全性・完全性・保守性・機密性)は、『Observability Engineering』第2版が土台とする Laprie 1995 の6属性と重なるが、Avizienis 2004 自体はオブザーバビリティを属性として扱っていない。オブザーバビリティを正式な第7属性として追加する動きは、ディペンダビリティのタクソノミー研究(セキュリティ工学系)側からはどう受け止められているか。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 1 What Is Observability?]], [[ディペンダビリティ]]) - **FDD が 2015 年に識別した「フィードバックマッピング」の技術課題は 2025 年時点でどこまで解消されたか**: Cito ら 2015 は「メソッドレベルの運用データ紐づけ」実装が重くなる・IDE レスポンスが低下するという技術課題を挙げた([[@2015__Onward!__Runtime Metric Meets Developer - Building Better Cloud Applications using Feedback]])。OpenTelemetry コード属性・継続的プロファイリング(Pyroscope, Polar Signals)・LLM コーディングアシスタントの登場でこれらの課題はどこまで解消されたか。特に LLM が過去の性能パターンを学習して「コード変更 → 性能インパクト」を推定する形態は FDD の予測ユースケースとどう接続するか。 - **LDFI(12章)が可観測性インフラ(コールグラフトレース)を「専門家の直感の自動化」に使う具体的な設計(冗長性をブール式でモデリングしSAT/ILPで実験選択する)は、本ページが蓄積してきたシグナル分類論(三本柱・CNCF 5シグナル)のどのシグナルに最も依存するか**。トレース以外のシグナル(メトリクス・ログ)はLDFIの定常状態モデリングにどう寄与しうるか、12章は明示しない。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 12 実験の選択に関する課題（と、その解決策）]] §12.2.1.1) - **「オブザーバビリティ=テレメトリ管理フレームワーク」(博士論文)と「オブザーバビリティ=ディペンダビリティの属性」(`Observability Engineering`)という2つの抽象化レベルは、実務上どちらの立場が設計判断に影響するか**: 前者の立場ではオブザーバビリティ基盤は計装・保持・分析のパイプライン設計問題に還元されるが、後者の立場では設計プロセス全体(要件定義・アーキテクチャレビュー)にオブザーバビリティ配慮を組み込むべきという含意を持つ。両者を採用する組織で実際の投資配分・意思決定にどう差が出るかを比較した研究はあるか。(Source: [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 2 Background]] §2.3, [[@2026__OReilly__Observability Engineering 2E - Chapter 1 What Is Observability?]]) ## 関連 - 概念: [[テレメトリ]]・[[分散トレーシング]]・[[トレース品質]]・[[DPDK性能分析]]・[[マイクロサービスアーキテクチャ]]・[[AIOps]]・[[根本原因分析]]・[[eBPF]]・[[限定観測可能性]]・[[GPU観測性]]・[[ゼロコード計装]]・[[GenAI オブザーバビリティ]]・[[ログ重複排除]]・[[継続的プロファイリング]]・[[ハードウェアカウンタ]]・[[ディペンダビリティ]]・[[オブザーバビリティデータモデル]]・[[フィーチャーフラグ]]・[[カナリアテスト]]・[[オブザーバビリティ駆動開発]]・[[MLモデル監視]]・[[カオスエンジニアリング]]・[[障害注入]]・[[インバンドネットワークテレメトリ]]・[[ネットワーク監視]]・[[システムズアプローチ]] / [[性能変化検知の正確性]] - エンティティ: [[OpenTracing]]・[[OpenTelemetry]]・[[OpenTracing Processor]]・[[Prometheus]]・[[Jaeger]]・[[Dapper]]・[[OBI]]・[[Brendan Gregg]]・[[Rudolf E. Kálmán]]・[[Charity Majors]]・[[Christine Yen]]・[[Honeycomb.io]]・[[Gartner]]・[[Peter Alvaro]] - ソース: [[@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]]・[[Scaling Telemetry Workloads in Cloud Applications]]・[[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 2 Background]]・[[Anomaly detection and root-cause identification in microservices]]・[[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.2 Data collection methods]]・[[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]]・[[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 1 イントロダクション]]・[[@2026__OReilly__Observability Engineering 2E - Chapter 1 What Is Observability?]]・[[@2026__OReilly__Observability Engineering 2E - Chapter 3 The Origins of Observability in Software]]・[[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]]・[[@2026__OReilly__Observability Engineering 2E - Chapter 25 The Observability Landscape Through a Systems Lens]]・[[@2024__OReillyJapan__SREをはじめよう - Chapter 14 Dickersonの信頼性の階層構造（良い出発点）]]・[[@2022__OReillyJapan__カオスエンジニアリング - Chapter 12 実験の選択に関する課題（と、その解決策）]] / [[@2026__ICPE__Benchmarking Change Detection Exactness and Overhead of Instrumentation and Sampling]] ## 関連エンティティ・ソース - [[CNCF]] / [[TAG Observability]] / [[OpenTelemetry]] / [[Prometheus]] / [[DPDK]] / [[Trace Compass]] - [[継続的プロファイリング]] — プロファイルシグナルの詳細概念 - [[@2026__ICPE__A Transparent and Efficient Performance Analysis Approach to Enhance DPDK Observability]] — DPDK native tracing と Trace Compass による低オーバーヘッド性能分析 ## 出典 - [[@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 の導入 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]] — Linux 可観測性ツールの2軸4象限分類、/proc・/sys・トレースポイント・kprobe・uprobe・USDT・PMC の情報ソース - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 1 イントロダクション]] — §1.7・§1.8、可観測性ツールと実験(ベンチマーキング)ツールの摂動の有無による区別 - [[@2026__OReilly__Observability Engineering 2E - Chapter 1 What Is Observability?]] — オブザーバビリティの制御理論的起源(Kálmán 1960)、ディペンダビリティの第7属性としての再定義、三本柱モデル対統合ストレージモデル - [[@2026__OReilly__Observability Engineering 2E - Chapter 3 The Origins of Observability in Software]] — Charity Majors による当事者史。2016年 Honeycomb 創業と6機能要件の導出、「モニタリングの再ブランディング」批判、Observability 1.0/2.0 の区分、AI が統合を後押しする力だとする個人的見解 - [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]] — オブザーバビリティを本番検証プラクティス群の土台(Practice 0)と位置づけるフライホイール論、フィーチャーフラグ・プログレッシブデリバリーとの依存関係 - [[@2026__OReilly__Observability Engineering 2E - Chapter 9 Observability-Driven Development]] — オブザーバビリティを「システムレベル」に限定しデバッガ/プロファイラとの役割分担を論じる、[[オブザーバビリティ駆動開発]]の定義 - [[@2026__OReilly__Observability Engineering 2E - Chapter 25 The Observability Landscape Through a Systems Lens]] — 三本柱モデル/統合ストレージモデルの2世代ツール系譜を開発者ループ/運用ループという組織的目的の軸で再対比する短章 - [[@2024__OReillyJapan__SREをはじめよう - Chapter 14 Dickersonの信頼性の階層構造（良い出発点）]] — David N. Blank-Edelman(山口能迪 訳), 『SREをはじめよう』, オライリー・ジャパン, 2024, 14章(§14.1.1: 監視/オブザーバビリティを信頼性ピラミッドの土台とする組織論的役割) - [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 9 モデルの監視と可観測性]] — Cathy Chen ほか, 『信頼性の高い機械学習』, オライリー・ジャパン, 2024, 9章§9.1.1(図9-1: ソフトウェア/データ/ML の3層可観測性モデル) - [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 12 実験の選択に関する課題（と、その解決策）]] — Peter Alvaro, 「実験の選択に関する課題(と、その解決策)」, Casey Rosenthal・Nora Jones 編『カオスエンジニアリング ― 回復力のあるシステムの実践』, オライリー・ジャパン, 2022, 12章(§12.2: コールグラフトレース(Dapper系譜)の診断偏重批判とSafety-IIによる学習志向への転換) - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] — Larry Peterson・Bruce Davie 著, 進藤資訓 訳, 『ネットワークシステムについて語るときに我々の語ること』, ラムダノート, 2026, 第11章 §11.5(オブザーバビリティを必須特性として位置づける主張、INTを第四の柱とする提案、開発者/運用者インセンティブの不整合、サービスメッシュによる非侵襲オブザーバビリティ) - [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 2 Background]] — §2.3(オブザーバビリティを「大規模テレメトリデータを管理するフレームワーク」と位置づける道具的定義) - [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.2 Data collection methods]] — §4.2(データ収集方法をログ・分散トレーシング・監視の3種に分類、各方法固有の限界)