Mackerelのアラート通知を制御する方法のご紹介

これは Mackerel Advent Calendar 2021 の21日目の記事です。

昨日は id:a-know さんによる Autify → Mackerel 連携 - 継続的なE2Eテストを監視するという記事でした。

今日は監視する上での悩みのポイントのひとつでもあり、最近よくお問い合わせをいただくアラート通知の制御方法について紹介したいと思います！

大量に発生するアラートの通知をまとめる
事前に認識しているアラートの発生や通知を抑止する
特定の監視ルールに関する通知を任意の通知チャンネルで通知する
まとめ

大量に発生するアラートの通知をまとめる

システムを運用していると、大小にかかわらず障害はつき物で、その障害に関するアラート通知を受け取ることがあると思います。

障害の原因や規模は様々ですが、広範囲になるほどその通知の量も増えていきます。

インフラ基盤の障害
単一障害点の影響を受けて、サービスを提供できずに発生する障害
- 例えばデータベースサーバーの障害に引きずられて、アプリケーションサーバーなどが障害となるようなケース
などなど…

2つ目のケースを例にすると、アプリケーションのログをERRORやFATALなどのログレベルで監視することはよくあると思いますが、数十〜数百台のサーバーにこのような監視ルールが適用されていると、データベースの障害によってそれらのホストから一斉にデータベースへの接続エラーが発生する（恐らくそのような場合のログレベルはFATALなどである）ことが予想されますよね。

こういった大量に発生するアラートを削減する機能として、アラートグループがあります。

mackerel.io

上記のヘルプページの通りグルーピングする対象を絞り込むことができますが、いきなり細かく設定するのではなく、まずはサービスで纏めて様子を見てから適切な粒度に分割して設定することをオススメします！

またアラートグループを設定する場合は、通知チャンネルでアラートグループ通知の設定を有効にする必要があるのでお忘れなく！！

事前に認識しているアラートの発生や通知を抑止する

「毎朝、午前4時のバックアップ処理で負荷が高くなって発生するアラート通知が煩わしい」といったケースはよくありますよね。

既知でかつそのアラートの発生が許容できる場合、Mackerelではダウンタイム機能を使うことで、サービス/ロールや監視ルールなどの条件に該当するアラートを曜日や時間帯などを指定して、その発生自体を抑止することが出来ます。

mackerel.io

上記の通りアラートそのものの発生を抑止してしまうため、アラートは発生させて通知だけを抑える事が出来ません。

そのような場合は、ホストのステータスをコントロールすることで制御できます。

mackerel.io

ホストのステータスにはworking、standby、maintenance、poweroffの4つのステータスがあり、standbyにすることで監視は実行（アラートが発生）するが、通知は行わないという動作になります。

この設定はホストごとにする必要があるので対象ホスト数が多いと設定が大変ですが、CLIツールの mkr を使うことで以下のようなワンライナーのシェルを実行するだけで一括して変更できます。

## サービスが "Service"、ロールが "Role" で、ステータスが "working" のホストを一括で "maintenance" に変更する
mkr update --status "maintenance" $(mkr hosts --service "Service" --role "Role" --status "working" | jq -r '.[].id')

## ステータスを "maintenance" から "working" に戻す
mkr update --status "working" $(mkr hosts --service "Service" --role "Role" --status "maintenance" | jq -r '.[].id')

このようにUI上で提供されていない操作も、mkrやAPIを使うことで柔軟に対応できるので、ぜひ運用に取り入れてみてください！