Let's DARK SOULS Ⅲ !! 最近PS4を買いました。インフラ担当の杉内です。
feedforceではMackerelでサーバ監視を行っていますが、使っていくにつれて監視ルールの変更をコードベースで管理したくなったので mkr を使ってコード化しました。
チーム内でデモを通して共有し、良さげな感じでしたので運用イメージも含めて共有します。
mkrを使って監視ルールを管理する
mkr
というコマンドラインツールからMackerelの監視ルールを更新したりできる(他にも機能はある)- 監視ルールは
monitors
というサブコマンドで操作する。さらにサブコマンドdiff
,pull
,push
がある - 監視ルールはjson形式で記述できる
ドキュメント → https://mackerel.io/ja/docs/entry/advanced/cli
準備
mkrのインストール
$ brew tap mackerelio/mackerel-agent
$ brew install mkr
$ mkr -v
go getでインストールしても良いです。
$ go get github.com/mackerelio/mkr
$ go install github.com/mackerelio/mkr
APIキーをdirenvを使用して設定します。APIキーは https://mackerel.io/orgs/
(ここではmackerel/
というディレクトリを作成して設定ファイルを管理しています。特に決まりはありません)
$ cd mackerel/
$ direnv edit .
export MACKEREL_APIKEY=<API key>
適当なコマンドを実行します。ホストの一覧が出て来ればOKです。
$ mkr hosts
準備ができたのでここからは実際に監視ルールを設定していきます。
監視ルールを更新する
mackerel/
以下で実行する- ディレクトリを変えずに -F mackerel/monitors.json で指定しても良い
- 監視のファイルは
monitors.json
- monitors.jsonが未管理の場合は
mkr monitors pull
をしてローカルファイルに保存する必要があります
まずdiff
で確認します。
$ mkr monitors diff
Summary: 0 modify, 0 append, 0 remove
管理画面と手元の設定ファイルに差分はありません。
次に何か設定を変更し(monitors.json
を変更)、再度diffします。
$ mkr monitors diff
Summary: 1 modify, 0 append, 0 remove
{
"name": "custom.delayed_job.process",
"type": "host",
"metric": "custom.delayed_job.process",
"operator": "<",
- "warning": 1.000000,
+ "warning": 2.000000,
"critical": 1.000000,
"duration": 10,
"scopes": [
"production: batch",
],
},
warningの閾値を 1 -> 2 へ変更しました。
- ここまで出来たらPRを作成してレビューしてもらう
- PRがマージされたら反映させるので以下へ
設定をMackerelに反映します。
$ mkr monitors push --dry-run (dryrunオプションで確認しても良い)
$ mkr monitors push
info Update a rule.
{
"id": "ホストID",
"name": "custom.delayed_job.process",
"type": "host",
"metric": "custom.delayed_job.process",
"operator": "<",
"warning": 2,
"critical": 1,
"duration": 10,
"scopes": [
"production: batch"
]
},
--dry-run
が成功してもpushしてからapiエラーになる場合もあります。
(必須項目が不足してたり)
管理画面から直接編集した場合
一度に多くの変更を加えるときなどは便利ですが、やはり管理画面から設定したほうが楽な場合は多いです。
- 新しく監視項目を追加するとき
- 緊急対応時とか
- 緊急対応でなくても画面から設定するのは問題無いです
その場合は管理画面を正としてコードをコミットします。
$ mkr monitors diff
$ mkr monitors pull
pullコマンドによって管理画面の設定がmonitors.json
に保存されるのであとはコミットしてPRを作成してください。
まとめ
- コードで管理されることによって変更点が可視化される
- diffができる、履歴が残る、レビューがされる
- GitHubを介すことによってアプリケーションと同じフローで監視ルールを設定できる
- chefやterraformと同じように
- 管理画面から編集するのは全然良くて、むしろ差分があるということを認識できるのが良いと思う
- そこは柔軟にやりたい
- CircleCIとの連携してもいいのでゆとりがあったらやりたい
- diffがあったらエラーにして管理画面から変更したのを忘れちゃわないようにするとか