時系列データからの実践的なアラートの最後になります。
ブラックボックスモニタリング
Borgmanは、ホワイトボックスモニタリングになります。この方式によりサービス内部の状態を把握することができます。そのため、サービス内部に起きている問題に対しては、強力な方法です。
しかし、ホワイトボックスモニタリングでは、システムの全体像について知ることはできません。
DNSのエラーで到達しなかったクエリやサーバーのクラッシュにより失ったクエリにアラートを発すことはできません。
この網羅できない問題に対して、GoogleはProberで解決を行いました。
Proberにより、HTTPレスポンスの検証を行います。その結果をBorgmanへ渡し、アラートを出すことができます。また、レスポンスのペイロードの検証し、その内容を確認することができます。
また、ロードバランサーの背後にProberを配置し、ロードバランスされたwww.google.comとデータセンター内のwebサーバー双方をモニタリングすることもできます。
これにより、データセンターの障害時、トラフィックの状態を知ることができます。エッジに問題が生じたときは、そのエッジをトラフィックフローのグラフから分離することができます。
設定のメンテナンス
Borgmanの設定はルールの定義をモニタリングの対象から分離します。
これにより、同じルールセットを複数のターゲットへ一斉に適用できるようになります。
また、ルール言語のテンプレートがサポートされています。それによりルールライブラリを構築することもできます。
これは複雑さを生み出すことがあります。そのため、ルールが期待通りに動作することを保証するために時系列データを合成し、広範囲のユニットテストと回帰テストを構築する方法も提供されています。
そして、このようなテストスイートの実行、設定のパッケージング、プロダクション環境のBorgmanへの設定のプッシュを行うCIも運用されています。設定が配布されると、Borgmanは内容を検証し、受け入れます。
そうして共通テンプレートライブラリが作成される中、2種類のモニタリング設定が急速に増えていきました。
1種類目は、エクスポートした変数で同じライブラリを使う場合は、テンプレートを再利用できるようにしただけのライブラリ。
2種類目は、単一のサーバー上のタスクからグローバルなサービスになるにつれて、生まれました。
エクスポートされた変数の汎用集計ルールを含むライブラリです。これにより、サービスのトポロジをモデル化することができます。
モデル化により、問題のデバックの際にサブコンポーネントをシステムの他の部分から分離できるようになります。この分割はラベルの付け方によって可能になっており、ターゲットのインスタンス名やシャード、データセンターなどにラベルを付けることができます。
まとめ
- モニタリングシステムはサーバーのスケールにメンテナンスコストが影響しないようにする。
参考文献
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 126-129