前々から書こうと思ってて, すっかり忘れてたので, 書きます!
Mackerelの監視
Mackerelでは, ホストの状態(CPU, メモリ, ファイルシステムの利用率とか, Mackerelと繋がっているかとか...)やURLの死活などを監視することが出来るのですが, 8月末に監視設定APIがリリースされ, これらのパラメータをAPI経由で実施出来るようになりました.
というわけでReactioの開発チームでも, 早速このAPIを利用して, 以下のような仕組みを作ることで, Mackerelの監視パラメータを"コード"で管理するようにしました.
仕組み
Reactioには, 開発者支援ツールが詰め込まれた「Reactio-HQ」というリポジトリがあるのですが, そこにMackerelの監視設定ファイルを用意しました. ちなみにReactioの開発者支援ツールは, ReactioそのものがPerl製のツールなのでそれに合わせてPerlで実装していて, この監視設定ファイルもPerlで扱える形式で書いています.
具体的には, こんな感じ(パラメータは適当です!).
use strict; use warnings; [ { id => "xxxxxxxxxxx", type => "host", name => "CPU %", metric => "cpu%", duration => 1, operator => ">", warning => 50, critical => 80, scopes => [], excludeScopes => [], }, { id => "xxxxxxxxxxx", type => "host", name => "Memory %", metric => "memory%", duration => 1, operator => ">", warning => 50, critical => 80, scopes => [], excludeScopes => [], }, { id => "xxxxxxxxxxx", type => "host", name => "Filesystem %", metric => "disk%", duration => 1, operator => ">", warning => 50, critical => 80, scopes => [], excludeScopes => [], }, ]
この設定ファイルを元にして実際に設定監視APIを叩く部分については, WebService::Mackerelの0.03で監視設定APIに対応するようになったので, これを使って「Mackerelの監視パラメータ変更スクリプト」を書いています(上記の設定ファイルも, WebService::Mackerelで使いやすい形で書いています).
後は, 「Reactio-HQ」リポジトリが更新される度, CIの仕組み(Reactioの場合, Jenkins)で「Mackerelの監視パラメータ変更スクリプト」を実行すれば, 常に最新の監視設定ファイルの内容がMackerelに適用される, という訳です.
利点
実際にやってみてよかったのは, 「謎のパラメータ変更」が生じ得ないという部分. 雑にブラウザから設定を変更していると, 「あれ, これって誰が変更したん...?」とか, 「これ, なんでこのパラメータになってるの...?」みたいな事, 起こりうると思うのですが, Mackerelの監視パラメータの設定をファイルに落としこみ, 更にそのファイルをGitリポジトリで管理することで, 「誰が」, 「いつ」, 「どのように」Mackerelの監視パラメータを変更したかについて, きちんと履歴が残せるようになりました.
また, BitBucketやGitHubを利用しているのであれば, Pull Requestベースで監視パラメータを変更していけるのも強みです. 実際, YAPC::AsiaでLTをしているときに, パラメータを低くしすぎてステージングからWARNINGが上がった後も, こういう感じのPull Requestを出して, パラメータの見直しを実施しました.
こうすることで, 「誰が」, 「いつ」, 「どのように」に加えて「どのような意図で」監視パラメータを変更したかまで記録に残すことが出来るので, 非常に便利です.