diaryこの広告は、90日以上更新していないブログに表示しています。Grafanaでモニタリングできるのはもうわかったので監視をどうするかというとAlertmanagerを使うことになります。Prometehus本体に比べればAlertmanagerはまだ成熟してないと思うけど、使う価値は十分にあると個人的にあると思ってます。その理由は2つあって、Prometehusで収集したメトリクスに対してアラートを設定できることと、アラート通知をまとめることができるということ。1番目はまあわかりますよね。GangliaでモニタリングしてNagiosで監視とかだとツールが分かれているのでやりづらい。Gangliaでモニタリング結果に対してNagiosでアラート通知できないからね。2番目が今日最も書きたかったこと。監視はナイーブにやると、いったんアラートがなったときに対処しない限り延々とアラートがなり続けることになります。あるプロセスが落ちてたら通知することを考えてみましょう。workerが10台起動しているものとして、10台じゃなくなったらアラート通知するとします。こんな感じのスクリプトをcronで5分間隔で実行するとします。send_notify関数で監視ツールにpostしていると思ってください。send_notify(message)fi夜中3時に9台になって誰も気づかなかったら延々と通知が来ますね。他のアラートが来ても埋もれそうですよね。それじゃあ辛いのでスクリプト側をこんな感じにしたとします。/tmp/presto.downfiこれならアラートは1回しか来ない!素晴らしい!でも復旧作業が終わったら/tmp/presto.down消す必要ありますけど、まあ忘れますよね。それにそもそもこの手の処理を監視スクリプト側に毎回入れないといけないのは辛い。ここではcronでチェックする例を入れましたけど、標準で用意されてそうなHDD使用率のチェックとかでもアラート通知洪水は起きがちですよね。levelで通知間隔を制御するものもあります。HDD使用率が90%を超えてたらlevelがerrorということで10分間隔で通知する、HDD使用率が95%を超えてたらlevelがfatalということで1分間隔で通知する。エラーが本当に深刻なものなら通知が来続けて欲しいという人も中にはいますが、僕の経験上、精神を疲弊させると思います。それに他のアラートが来ても埋もれそうになる問題は避けられない。メール通知ならメーラーのフィルタリングで頑張るという手もあるかもしれませんが。前置きが長くなりましたが、そこでAlertmanagerですよ。Alertmanagerはこんな感じでルールを書きます。IFのところがアラートの条件ですね。この例だとupが0の状態が5分超えたらアラート。FORの部分のおかげで突発的なものはフィルタリングできます。LABELSとANNOTATIONSは補足情報ですね。}Prometheusの世界ではアラートもメトリクスです。アラートがなると下記メトリクスが1になります。...}alertnameでグルーピングされるので、同じアラートが延々きつづけることはありません。最初のアラートが来て何も対処しない状態だと4時間後に再度アラートが来ます。この設定はrepeat_intervalです。モニタリング対象ホストにexporterをsetupしてメトリクスをPrometheusサーバーからpullしてそれに対してアラートを設定するのが一般的です。上記の例みたいにcronでチェックしたい場合もあるでしょう。その場合はAlertmanagerに直接POSTすることもできます。workerの例だとこんな感じ。}]EOSこれでアラート通知洪水に悩まされることも無くなります。5m)の時間が経ってもアラートがPOSTされてこなかったら解決したとAlertmanagerが判断してます。Alertmanagerの通知方法として僕はwebhookを使っているんですが、デフォルト設定だとアラート発火と解決の両方のタイミングで通知があります。send_resolvedをfalseにすればおそらくアラート解決の通知は来ないと思います。そんなわけで、Alertmanagerには通知を工夫している部分が感じられるので将来有望なソフトだと思ってます。