Webエンジニアの森脇です。現在、障害通知の最適化を進めており、その第一弾としてMackerelのアラートグループ機能を利用して、障害通知の抑制をしました。手軽に実現ができ、便利だったので紹介します。
当初の課題
LCLでは、Mackerelを利用して各サーバのメトリクス監視やサービスの外形監視をしています。アラートが発生するとチャットへ通知していますが、大規模な障害発生した場合は、以下のようにアラート通知でチャットが埋まってしまっていました。
チャットがアラート通知で埋まってしまうことにより、障害対応の妨げになる問題が多く発生していました。
- 障害対応のやりとりをしても、アラート通知ですぐに流れてしまう
- 大量の通知がノイズとなり、障害対応への集中を削がれる
- OK/NGのアラートが個別に通知され、すべてOK状態になったかチャット上で判断しづらい
すぐに解決策が見つからず放置になっていましたが、7月ごろにMackerelでアラートグループ機能のリリースがあり、今回利用するに至りました。（リリースから、少し間が空いてしまいましたが）
アラートグループ導入による改善
Mackerelのアラートグループを使うと、個別のアラートがまとめて通知されるため、チャットへの通知が抑制されました。複数のアラートが発生しても、以下のようにグループ単位で通知されます。（もちろん、今まで通り個別に通知することも可能です）
全ての個別アラートがOKになった段階で、アラートグループのOK通知がくるため、障害の完了が明確になりました。
アラートをグルーピングする単位は、サービス・ロール単位や個別のアラートごとにも設定できます。このあたりがよく考えられていて、状況に応じて最適なグルーピングができると思います。LCLでは、サービス単位でアラートグループを設定しています。
サービス単位でアラートグループを作ると、障害がどのようなアラートを経て発生したかが容易にわかります。以下の例だと、データベースが高負荷となりWarning、Criticalのアラートが発生し、外形監視のアラートへつながったことが時系列で表現されています。
まとめ
アラートグループ機能によって、障害通知で問題になっていた点が大きく改善できました。今後は、さらに最適な通知フローにするため、PagerDutyというサービスも活用していく予定です。PagerDutyの活用については、また記事を書きたいと思います。
