# Monitoring Navigation: [[index]] | [[overview]] ## 概要 SRE Workbook の監視章であり、メトリクス、テキストログ、構造化イベントログ、分散トレーシング、実行時イントロスペクションのうち、特にメトリクスと構造化ログを SRE の基本監視ニーズに適したデータ源として整理する。監視の用途は、注意を要する状態へのアラート、調査・診断、可視化、容量・健全性の長期傾向把握、変更前後や実験群の比較である。 この章は、監視システムの機能選定、ログとメトリクスの使い分け、監視構成の管理、目的を持つメトリクス設計、アラートロジックのテストまでを扱う。SRE Book の [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]] が監視哲学を提示したのに対し、本章は「どのデータをどこへ流し、どの構成をどう管理し、どうテストするか」という運用設計へ踏み込む。 ## 主要主張 - データ鮮度はインシデント対応速度に直接影響する。原因となる操作と監視上の結果の間に 4〜5 分以上の遅延があると、誤った相関や無効な判断を誘発しうる。 - 長期傾向分析には複数月のデータ保持が必要だが、全詳細メトリクス保持は高価であり、用途に応じて集約粒度を選ぶ必要がある。 - メトリクスは単調増加カウンタとして保持すると、リクエスト率や SLO バーン率のような窓関数計算に適する。 - パーセンタイルは平均よりもレイテンシの悪化を見つけやすい。平均は 50%、5%、1% のどのリクエストが遅いのかを隠す。 - アラートは分類と抑制が必要だ。全ノードで同じ高エラー率が出ている時にノードごとに通知するとノイズになる。 - ログは高粒度で正確だが遅延しやすく、メトリクスは低粒度だが近実時間でアラートに向く。Google ではアラートとダッシュボードは主にメトリクス、根本原因調査はログに寄る。 - 監視構成はコードとして扱い、レビュー、履歴、ロールバック、静的検査を可能にすべきである。 - 監視システムは収集、保存、アラート、可視化を分け、安定したインターフェースで疎結合にすると、コンポーネント交換と移行が容易になる。 - 監視とアラートもテスト対象であり、メトリクス出力、監視ルール評価、通知経路の 3 層で検証するのが望ましい。 ## 章の構造 ### 望ましい監視戦略の特性 - データ鮮度と取得速度: ページ通知やインシデント中の操作判断に影響する。 - 計算能力: 長期保持、窓関数、パーセンタイル、オフライン分析のための raw データ保存。 - 可視化: グラフ、テーブル、ヒートマップ、ヒストグラム、対数スケールなどを対象読者に合わせる。 - ドリルダウン: マシン種別、サーババージョン、リクエスト種別などの集約軸で相関を探索する。 - アラート分類と抑制: 重大度別通知と依存障害・全体障害時の通知爆発抑制。 - 統制水準: 自社運用か第三者サービスかは必要な制御水準で決まる。 ### 監視データ源 - メトリクス: 近実時間、低粒度、アラートとダッシュボード向き。 - 構造化ログ: 高粒度、正確、アドホック分析や根本原因調査向き。 - App Engine 事例: HTTP ステータスコードをメトリクスラベル化し、エラー種別別グラフとアラートを可能にした。 - Ads SRE 事例: ログ処理スクリプトとメトリクスアラートの不整合を、リクエスト時にユーザー影響を判定するライブラリで解消した。 - entity ID 事例: 高カーディナリティな ID はメトリクスラベルにせず、アラートメールから実行できるログ検索スクリプトで認知負荷を減らした。 ### 監視システム管理 - 監視設定をコード化し、変更履歴、レビュー、ロールバック、リンティングを可能にする。 - 大規模組織では、中央集約による一貫性とチーム個別制御のバランスが必要である。 - 基本メトリクスを共通ライブラリやサービスメッシュで簡単に出せるようにすると、新規コンポーネントも自動的に基本監視を持つ。 - Zabbix のような一体型から、Prometheus、InfluxDB、Alertmanager、Grafana のような分離型へ設計が移行している。 - Borgmon から Monarch への移行時、Viceroy を独立ダッシュボードサービスにしたことで、監視システム移行の要求を減らした。 ### 目的を持つメトリクス - SLI メトリクスは SLO ベースアラート発火時に最初に見るべき指標であり、サービスダッシュボードのランディングページに置くべきである。 - SLO ダッシュボードは違反を示すが原因までは示さないため、変更、依存関係、リソース、レスポンスコード、クォータ拒否などの調査用メトリクスが必要である。 - 本番変更の監視では、バイナリバージョン、コマンドラインフラグ、動的設定バージョンを可視化する。 - 依存関係は RPC クライアントライブラリなど低レベルで一度だけ計装すると、一貫性が高く新しい依存も自動監視できる。 - メトリクスは容易に出せるから出すのではなく、アラート用かデバッグ用か、どの意思決定に使うかを明確にする。 ### アラートロジックのテスト - Google では合成時系列を作るドメイン固有言語で監視とアラートをテストする。 - 推奨される 3 層は、バイナリのメトリクス出力、監視構成のルール評価、アラート構成の通知経路である。 - アラートルールは数か月から数年発火しないことがあるため、発火条件に達したとき適切な人へ意味のある通知が行くことを事前に検証すべきである。 ## 既存 SRE Book との関係 - [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]] は監視の基本定義、4 つのゴールデンシグナル、ページすべき症状中心の哲学を提示する。本章は、それをデータ鮮度、ログ対メトリクス、構成管理、疎結合アーキテクチャ、テストへ具体化する。 - [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]] の Borgmon 系譜を、Borgmon から Monarch と Viceroy への分離移行という実例で補強する。 - [[@2016__OReilly__SRE Book - Chapter 12 Effective Troubleshooting]] とは、ログを根本原因調査に使い、アラートから調査スクリプトへ直接つなぐ実務設計で接続する。 ## 重要概念候補 - [[テレメトリ]]: メトリクス、構造化ログ、分散トレーシング、イントロスペクションを用途別に整理する概念として更新候補。 - [[監視戦略]]: データ鮮度、取得速度、計算、可視化、アラート抑制、統制水準を含む新規 concept 候補。 - [[監視設定 as Code]]: 監視構成をコードとして扱う実践。[[Infrastructure as Code]] と接続候補。 - [[目的を持つメトリクス]]: アラート用、デバッグ用、容量計画用の目的を明確化する設計原則。 - [[メトリクスとログの使い分け]]: 近実時間の通知はメトリクス、高粒度の根本原因調査は構造化ログという分担。 - [[アラート抑制]]: 依存障害や全体障害時の通知爆発を避ける仕組み。 - [[監視テスト]]: メトリクス出力、ルール評価、通知経路をテストする 3 層。 ## 実体候補 - [[Google]] - [[Google SRE]] - [[App Engine]] - [[Google Ads]] - [[Borgmon]] - [[Monarch]] - [[Viceroy]] - [[Prometheus]] - [[OpenMetrics]] - [[Alertmanager]] - [[Grafana]] - [[InfluxDB]] - [[Zabbix]] - [[statsd]] - [[OpenCensus]] - [[Istio]] - [[BigQuery]] - [[Cloud Dataflow]] - [[Data Studio]] - [[Jess Frame]] - [[Anthony Lenton]] - [[Steven Thurgood]] - [[Anton Tolchanov]] - [[Nejc Trdin]] - [[Carmela Quinito]] ## 統合時に更新すべき既存ページ候補 - [[テレメトリ]]: メトリクスとログの役割分担、目的を持つメトリクス、SLO アラートから原因調査へ移るダッシュボード設計を追加。 - [[SRE]]: 監視がサービス健全性判定と診断の前提であり、SRE が監視システムの特性を理解すべきという原則を追加。 - [[根本原因分析]]: ログが高粒度の根本原因調査に向き、アラートメールからログ検索スクリプトへつなぐ設計を追加。 - [[サービスレベル目標]]: SLI メトリクスをダッシュボードの入口に置くべきという運用設計を追加。 - [[分散トレーシング]]: 本章では中心扱いではないが、監視データ源の一つとしてログ・メトリクスと補完関係にある。 - [[Infrastructure as Code]]: 監視設定もコードとして扱う実践を関連知見として追加。 ## 未解決の問い - 高カーディナリティメトリクスが一般化した現在、entity ID のような値をメトリクスにしないという判断はどこまで維持されるか。 - SLO ダッシュボードと原因調査ダッシュボードの分離は、LLM エージェントによる障害調査ではどのようにプロンプト/ツール境界へ写像されるか。 - 監視・アラートのテストは、Prometheus 系の単体テストだけでなく、通知経路やオンコール行動まで含めてどこまで自動検証できるか。 ## 出典 - Raw: `.raw/articles/monitoring-2026-06-07.md` - URL: https://sre.google/workbook/monitoring/