> [!abstract] > Google の内部モニタリングシステム Borgmon を題材に、時系列データに基づく実践的なアラーティング手法を解説した章である。従来の命令型チェックスクリプトから宣言型ルール評価への転換、ラベルセットによる多次元時系列モデル、階層型アグリゲーション、Alertmanager による重複排除とルーティング、そしてブラックボックスモニタリング（Prober）との相補的な設計を通じて、モニタリングの保守コストをサービス規模に対して劣線形に抑える原則を示す。 ## 書誌情報 - タイトル: Practical Alerting from Time-Series Data（Chapter 10） - 著者: Jamie Wilkinson（編集: Kavita Guliani） - 書籍: [[SRE Book]]（Site Reliability Engineering: How Google Runs Production Systems, O'Reilly, 2016） - URL: https://sre.google/sre-book/practical-alerting/ ## Borgmon の誕生と設計思想 Borgmon は 2003 年頃、Borg クラスタ管理システムと並行して誕生した Google 内部のモニタリングシステムである。従来のモニタリングはターゲットごとにチェックスクリプトを実行する命令型であり、ターゲット数に比例して負荷が増大した。Borgmon はメトリクスを並列に収集し、ルールを一元的に評価する宣言型モデルへ転換することで、スケーラビリティの問題を解消した。 ホワイトボックスモニタリングの手法を採り、各アプリケーションが HTTP エンドポイント（`/varz`）から標準化されたメトリクスを公開する方式を確立した。オープンソースの Prometheus、Riemann、Heka、Bosun は Borgmon と同等の機能を提供しており、とくに Prometheus は Borgmon の設計から直接的な影響を受けている。 ## 計装とメトリクス収集 アプリケーションは `/varz` ハンドラを通じて、1 行 1 変数のプレーンテキスト形式でメトリクスを公開する。計装（instrumentation）の導入障壁が低いため広範な採用が進む一方、公開変数の増加に伴う保守負担のトレードオフが生じる。 Borgmon は設定されたターゲットから定期的にメトリクスを取得する。各ターゲットに対して実際のメトリクス値に加え、収集自体の成否を示す合成変数（synthetic variable）も記録する。ターゲットの発見には Borg の名前解決システム（BNS）に基づくサービスディスカバリ機構を用いる。 ## 時系列データモデル データは `(タイムスタンプ, 値)` のペアとしてメモリ上に格納され、ラベルセットで多次元的に組織化される。たとえば `{var=http_requests, job=webserver, instance=host0:80, zone=us-west}` のように複数のラベルで一意に識別される。 固定サイズの「時系列アリーナ」は 1 データポイントあたり約 24 バイトを消費し、ガベージコレクションにより通常約 12 時間分のデータを RAM 上に保持する。単一の Borgmon で約 100 万の時系列を保持できる。より長期のデータは外部の TSDB（Time-Series Database）にディスク上でアーカイブされる。 ## ルール評価と代数的演算 Borgmon は時系列データに対する代数的な式を実行し、インスタンスをまたいだアグリゲーションを計算する。主要な演算には以下がある。 - **`rate()`**: 指定した時間窓におけるカウンタの変化率を算出する - **`sum without instance()`**: インスタンスラベルを除去しつつタスク間の値を合計する - **ラベルフィルタリング**: `code=!/200/` のような正規表現パターンで特定値を除外する 変数名は `アグリゲーションレベル:メトリクス名:演算_時間窓` の規約に従う（例: `dc:http_errors:ratio_rate10m`）。ルールは固定間隔で評価され、過去に計算した結果を参照できるため、多段階のアグリゲーションパイプラインを構築可能である。 ### アラートルールの例 ``` {var=dc:http_errors:ratio_rate10m,job=webserver} > 0.01 and by job, error {var=dc:http_errors:rate10m,job=webserver} > 1 for 2m => ErrorRatioTooHigh ``` このルールはエラー率が 1% を超過し、かつ絶対的なエラー数が毎秒 1 件を超えている状態が 2 分間持続した場合にアラートを発火する。二重条件により統計的に無意味な少量のエラーでの誤報を防止する。`for 2m` 節はフラッピング防止のために最小持続時間を要求する仕組みである。 ## Alertmanager Alertmanager はアラートの一元管理を担うサービスであり、以下の機能を提供する。 - **重複排除**: 複数のデータセンタの Borgmon が同一のアラートを発火した場合に統合する - **抑制**: クリティカルなアラートの発火時に低優先度のアラートを抑止する - **ルーティング**: オンコールローテーション、チケットシステム、通知チャネルへの適切な振り分けを行う - **グルーピング**: 関連アラートをまとめ通知疲れを軽減する ## 階層型トポロジ 大規模なデプロイでは Borgmon を階層化する。 1. **スクレイパ層**: クラスタ内の個別タスクからメトリクスを収集する 2. **データセンタ層**: ゾーン内でデータをアグリゲートする 3. **グローバル層**: データセンタ間をまたぐ横断的なビューを構築する 層間の時系列転送にはストリーミングプロトコルを用い、テキスト形式の `/varz` より帯域効率を高めている。非常に大規模なサービスではモニタリングトポロジ自体をシャーディングし、複数の Borgmon がターゲットを分担する。 ## ブラックボックスモニタリング（Prober） Borgmon のホワイトボックスモニタリングを補完するのが Prober システムである。HTTP や DNS などのプロトコルレベルでの外部チェックを実施し、ユーザから見える振る舞いを検証する。たとえば DNS エラーによりリクエストがサーバに到達しない障害は、内部メトリクスからは検知できないが、Prober であれば捕捉できる。 ホワイトボックスは「なぜ壊れているか」と「もうすぐ壊れそうなもの」を示し、ブラックボックスは「今ユーザに何が見えているか」を示す。両者の併用が網羅的な障害検知の要件である。 ## 設定管理とテンプレート ルール定義をターゲット定義から分離することで、システム間の再利用が可能になる。2 種類のテンプレートが確立された。 1. **ライブラリスキーマ**: 共通ライブラリ（HTTP サーバ、RPC、ストレージクライアント）が出力する標準メトリクスを体系化したもの 2. **アグリゲーションテンプレート**: サービストポロジのモデリングに使う汎用ルール デプロイ前の継続的インテグレーション（CI）で構文エラーや意味的な不整合を早期に検出する。 ## 実践的指針 - メトリクス収集とアラート評価を分離し、保守コストがサービス規模に対して劣線形に増加するよう設計する - 命令型チェックスクリプトではなく宣言型ルール評価を採用し、モニタリングのスケーラビリティを確保する - アラートには最小持続時間（`for` 節）を設け、フラッピングと偽陽性を抑制する - エラー率の閾値だけでなく絶対数の閾値も併用し、統計的に有意な異常のみを検知する - ホワイトボックスモニタリング（Borgmon）とブラックボックスモニタリング（Prober）を組み合わせ、内部状態とユーザ体験の双方をカバーする - ルール定義をテンプレート化し、CI でバリデーションを行い、設定の品質と再利用性を担保する - 大規模環境では階層型トポロジとシャーディングでモニタリング自体のスケーラビリティを確保する ## 関連 - [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]]: 4 つのゴールデンシグナルとモニタリング設計の基盤 - [[@2016__OReilly__SRE Book - Chapter 1 Introduction]]: SRE の基本原則 - [[SRE Book]]: 書籍全体 - [[SRE]]: SRE の概念定義 ## 出典 - Wilkinson, J., "Practical Alerting from Time-Series Data," in Beyer, B. et al., *Site Reliability Engineering: How Google Runs Production Systems*, O'Reilly, 2016