今回から待ちに待った実践編に入ります。
マズローの欲求階層にならい、プロダクション環境にも欲求階層があります。より高い階層の欲求を満たすためには下位の階層を満たす必要があります。
上位から、プロダクト、開発、キャパシティプランニング、テスト及びリリース、ポストモーテム/根本原因分析、インシデント対応、モニタリングがあります。
今回は、時系列データからアラートを通知する実践的な方法を学んでいきます。
モニタリングにより、インシデント対応へ正しいアプローチをすることができ、またサービスの達成度の計測を行うことができます。
大規模なシステムにおいて、モニタリングが難しいことにはいくつか理由があります。
例えば、以下のような場合があります。
- 分析の対象となるコンポーネント数そのもの。
- メンテナンスの負荷を適度に低く保たなければならない
大規模なシステムにおけるモニタリングシステムは、１台のマシンの障害でアラートをだすことはできません。なぜなら、多すぎるアラートは対応することができないためです。その代わりにシステム自体に障害に対する耐性をもたせることが重要です。
モニタリングシステムにおいては、サービスに関する高レベルのアラートを出しながらも、個々のコンポーネントの調査もできることが求められます。
Googleにおいては、10年にわたり、モニタリングシステムが進化してきました。
Borgmonの誕生
Borgmanは、Borgを補完するために作られたモニタリングシステムです。
Borgmanでは、共通のデータ公開フォーマットを利用します。これによりデータ変換などのオーバーヘッドをなくすことができます。データは、グラフの描画やアラートの生成に使われ、通常はクラスタごとにBorgmanを起動します。
Borgmanでは、単一のターゲットのすべてのメトリクスの収集を１回のHTTPのフェッチで行えるようになっています。以下は、取得時の例です。
curl http://webserver:80/varz
http_requests 37
errors_total 12アプリケーションのインスツルメンテーション
/varzのHTTPハンドラは単純に、１行につき１つの変数をキーと値を空白で区切り、すべてのエクスポートされた変数をプレーンテキストで返します。後にマップ方変数の機能が追加されたので、エクスポートする側がいくつかのラベルを変数名に対して定義し、値のテーブルやヒストグラムをエクスポートできるようになる。
以下に示すのは、25個のHTTP200のレスポンス、12個のHTTPのレスポンスを含むマップ型です。
http_responses map:code 200:25 4040:0 500:12プログラムにメトリクスを追加したい場合は、メトリクスが必要なところで1つの宣言をコードに追加すればできます。
変数の定義とBorgmonにおける変数の利用が分離されているので、変更管理に注意が必要になります。
しかし、これは後に、ルール生成と検証を行うツールが作成され、解消されました。
まとめ
- プロダクション環境の欲求階層は重要。
- Borgmanというモニタリングシステムが作られた。
参考文献
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 113-116