はじめに
ちょうどいま仕事で監視アラートの設計をしているので記事にします。
アラートは必要最小限にすることが望ましいと考えてます。
足りていなければ障害に気付くことができないですし、
逆に闇雲にあらゆることをアラートしても疲労させて関心が薄れてしまいます。
このバランスは実際に運用しながら調整していくことが理想なので、 いきなり100％の設計をするのは困難だと思います。
私は運用の実績が少ないので、まずは設計から行い、 机上ベースで良いアラートを考えていきたいと思います。
アラートの定義
アラート
緊急の対応が求められ、そのままだと利用者がシステムを使えない状態になるものです。 例えば、死活監視でログインの失敗が上限を超えたケースです。 Slackなどのメッセージ通知や電話で行います。
アラートでないもの
直ぐに対応しなくても影響が出ないものはアラートではなく警告とします。 例えば、夜間のバックアップジョブが失敗したというケースです。 叩き起こしてまで対応しなくてよいので、Slackなどのメッセージ通知のみとします。
アラートの目的
アラートはシステム監視をするための一つの方法であり、アラートを送ることは目的ではありません。 何を監視したいのかは、システムやチームごとに変わるので目的も変わってくるはずです。 例えば、セキュリティインシデントをアラートするケースです。（やるべきだが今回はスコープ外）
私が設定した目的
- システムが利用者視点で現在/未来、正常に動いていること/動くことを監視する
ポイントは利用者視点で動いているか、という点と 現在動いているかどうかだけでなく、動かなくなる予兆がないかを監視することです。
利用者視点で動かなくなる予兆がある例としては、 APIコンテナのオートスケールの上限値に達したというケースです。 一見、予兆というと警告でもよさそうですが、このケースでは近いうちに大量のアクセスを捌けなくなるのでアラート扱いにします。この例は閾値をもう少し下げて警告しておくことでこの事態は避けることができそうです。
何をアラートするか
前置きが長くなりました。ここからが本題ですが、続きは後編として書きます。
参考文献
監視を始めるときは是非読みたい本です↓
入門 監視 ―モダンなモニタリングのためのデザインパターン
