> [!abstract] 概要 > CNCF TAG Observability が 35 名以上のコミュニティメンバーにより作成したホワイトペーパー（v1.0、2023年10月）。クラウドネイティブシステムのオブザーバビリティを、制御理論の概念から実践的なシグナル選択・相関・アラート設計まで体系的に整理する。対象読者は SRE・DevOps エンジニア・ソフトウェアエンジニア・インフラ担当者。 ## 論文情報 - **タイトル**: Observability Whitepaper - **著者**: Alex Jones, Alois Reitbauer, Bartłomiej Płotka, Liz Fong-Jones, Michael Hausenblas ほか 35 名（アルファベット順） - **発行**: CNCF TAG Observability、v1.0、2023年10月 - **URL**: https://github.com/cncf/tag-observability/blob/main/whitepaper.md - **関連エンティティ**: [[CNCF]]・[[TAG Observability]] ## 概要 オブザーバビリティを制御理論の概念として定式化し、5 種のシグナル（メトリクス・ログ・トレース・プロファイル・ダンプ）の特性と適切な使い方、シグナル間相関の機構、SLO ベースのアラート設計を網羅する。「データを溜め込むのではなくビジネス目標に紐づいたシグナルを意図的に収集する」ことを一貫した設計思想とし、現状のエコシステムギャップ 4 点も整理する。 ## 問題設定 クラウドネイティブシステムの複雑化により、単一のシグナルや監視ツールでは内部状態を十分に推測できなくなっている。シグナル種別の役割分担とシグナル間の相関方法論が整理されないまま「とにかくデータを集める」アンチパターン（データレイク化）に陥る組織が多い。本書はこの問題意識から、シグナル間の設計指針と相関手法を体系化する。 ## 5 シグナルの詳細 ### メトリクス 数値表現（Numeric representations）のデータ。**ゲージ**（任意方向に変化する値）・**カウンタ**（単調増加する累積値）・**ヒストグラム**（バケット別分布）の 3 種が基本。リアルタイム監視・トレンド分析・キャパシティプランニングに適し、ストレージ効率が高い。 **メトリクス基数問題**：ある期間に収集される一意なメトリクス系列数を「基数（cardinality）」という。PID ラベルを heap-memory メトリクスに付与すると 64bit 系では〜400 万 PID × 再起動ごとの更新で爆発的に基数が増加する。「安定した次元でのみラベル化する」原則が重要で、ホスト名をポッド名に替えるだけで基数を数十億から 3 万に削減できる。メトリクスストレージは基数に線形スケールするため、コスト管理の実質的なレバーとなる（Source: [[.raw/articles/cncf-observability-whitepaper.md]]）。 ### ログ テキストエントリ。**アプリケーションログ**・**セキュリティログ**・**システムログ**・**監査ログ**・**インフラログ**の 5 カテゴリ。ログレベルは ERROR / WARNING / INFO / DEBUG の 4 段階。フリーフォームテキストのため解釈コストが高く、メトリクスやトレースへの変換が推奨される用途も多い。収集経路は (1) 中央リポジトリへ直送、(2) メッセージキュー経由のフィルタ・エンリッチ、(3) OpenTelemetry / Fluentd / Fluentbit 等のコレクタの 3 パターン（Source: [[.raw/articles/cncf-observability-whitepaper.md]]）。 セキュリティ要件: 保存時・転送時の暗号化必須。PII を保存しない。ログは配信保証のないメカニズムであり、重要データには別の冗長化が必要。 ### トレース（分散トレーシング） 分散トランザクション（エンドユーザーが起点となるリクエストとダウンストリームへの全影響）を記録する技術。スパンの木構造で表現され、ガントチャートとして可視化される。**W3C Trace Context 仕様**がコンテキスト伝播の国際標準であり、OpenTelemetry・.NET など主要プロジェクトが採用。計装には「コンテキスト伝播」と「スパンマッピング」の 2 目的があり、HTTP クライアント/サーバーライブラリが透過的に担うことが多い。詳細かつ高コストなシグナルであるため、継続収集より特定調査に適する（Source: [[.raw/articles/cncf-observability-whitepaper.md]]）。 ### プロファイル（継続的プロファイリング） 他のツールが「何が起きているか」を示した後、「なぜそうなっているか」をコードレベルまで掘り下げるシグナル。CPU・Heap・GPU・Mutex・IO プロファイラ等があり、サンプリングプロファイラにより本番環境での計装オーバーヘッドが数% 以内に抑制可能になった。時間軸を加えることで俯瞰と詳細の両方を提供し、アイシクルグラフで CPU 時間の関数別割合を可視化する（Source: [[.raw/articles/cncf-observability-whitepaper.md]]）。 ### ダンプ（コアダンプ） クラッシュ時のプロセスメモリイメージ。クラウドネイティブ環境では特有の課題がある——(1) アクセス制御の分散（アプリケーションオーナーとインフラオーナーで責任が分かれる）、(2) ポッド再起動前の永続化。大規模クラスタではダブルデジットGBサイズのダンプがストレージ・ネットワークのボトルネックになる。Linux カーネルへの名前空間付き `core_pattern` サポートの RFC が 6 年以上未解決（Source: [[.raw/articles/cncf-observability-whitepaper.md]]）。 ## シグナル間相関 複数シグナルをサイロで管理せず「シームレスに行き来できる」設計が重要。3 機構: 1. **一貫したターゲットメタデータ**: cluster / environment / pod / container_name 等のラベルを全シグナルで統一することで、同一ターゲットの別シグナルへ横断できる 2. **タイムウィンドウ**: タイムスタンプによるミリ秒単位のフィルタリング 3. **リクエスト ID / トレース ID の統一**: ロギングとトレーシングの計装を統合し、同一 Trace ID をログ行に付与する **Exemplar（エグザンプラー）**: 集約メトリクス（例: エラーカウンタ）に代表的なトレース ID を添付する仕組み。「大量リクエストのアラート時に代表例 1 件だけトレースを辿れる」という橋渡し。Prometheus・OpenTelemetry SDK が対応。実装には計装コードの変更が必要（将来は自動計装で透過化可能）（Source: [[.raw/articles/cncf-observability-whitepaper.md]]）。 ## SLO / SLA / SLI とエラーバジェット | 用語 | 定義 | |---|---| | SLI（Service Level Indicator） | 提供サービスの品質の定量的指標（例: テールレイテンシ、エラー率） | | SLO（Service Level Objective） | SLI の目標値または範囲（例: 99.9% 成功）。リリース目標としても機能する | | SLA（Service Level Agreement） | SLO を含むビジネス契約。違反時の結果を規定する | | エラーバジェット | SLO が許容する失敗の許容量（= 100% − SLO）。30日・99.9% SLO では 43 分が予算 | ステークホルダーの同意が必須: プロダクトマネージャー（ユーザー許容度の確認）・開発者（予算枯渇時のリスク低減へのコミット）・運用チーム（過度なトイル・バーンアウトなしでの防御可能性確認）（Source: [[.raw/articles/cncf-observability-whitepaper.md]]）。 ## アラート設計 「SLO ベースのアラートを使うこと」が推奨方針。3 アプローチ: **1. ターゲットエラー率**: 短いウィンドウ（10分）のエラー率が SLO を超えたら発火。単純だが偽陽性が多い。 **2. バーンレートアラート**: エラーバジェットの消費速度を監視。バーンレート 1.0 = SLO ウィンドウ終了時に丁度予算を使い切る速度。バーンレート 2.0 = 半分の時間で枯渇。 | バーンレート | エラー率 | 枯渇予測（30日・99.9% SLO） | |---|---|---| | 1 | 0.1% | 30日 | | 2 | 0.2% | 15日 | | 10 | 1% | 3日 | | 1000 | 100% | 43分 | 30日予算の 5% を 1時間で消費するにはバーンレート ~36 が必要。Prometheus 実装: ```promql (sum(rate(http_requests_total{code=~"5.*"}[1h])) / sum(rate(http_requests_total[1h]))) > 36 * .001 ``` **3. 機械学習ベースの異常検知**: 季節性やロールアウトを考慮した閾値の自動調整。ページングへの使用は議論があるが、トラブルシューティングのヒントとしては価値が高い（Source: [[.raw/articles/cncf-observability-whitepaper.md]]）。 ## エコシステムのギャップ（2023年時点） 1. **自動/非侵襲計装の不足**: アプリケーションオーナーがソースコード変更を要する場面が多い 2. **標準クエリ層の欠如**: 可観測性ツールごとに固有 DSL があり互換性なし。OpenTelemetry が計装/収集を標準化したように、クエリ層の標準化が必要 3. **ログ/トレース/プロファイルの OSS DB が CNCF 未収録**: メトリクス（Prometheus/Thanos/Cortex）は成熟しているが他は CNCF 外 4. **ストリーミング API 監視方法論の不在**: USE/RED 手法は gRPC ストリーミングに適用困難 ## 強み / 弱点・課題 **強み**: - シグナル間相関の実践的フレームワーク（メタデータ統一・Trace ID 統一・Exemplar）が具体的で実装可能 - SLO ベースのバーンレートアラートをメトリクス計算式・表付きで説明しており即座に実装可能 - 制御理論的定義とコミュニティのベストプラクティスが一体化しており概念と実践のギャップが少ない **弱点・課題**: - プロファイルとダンプはツールエコシステムの未成熟さゆえ「今後に期待」の記述が多い - ギャップの提示にとどまり解決策の提示がない箇所が多い - 2023年時点の情報であり、OpenTelemetry の急速な発展（自動計装等）で既に改善されているギャップもある