Amazon Cloudwatch Alarm の設定をcsvで管理する

ツール導入前の課題

アラート監視自体は行なっていたものの、AWSの設定変更したあとに監視設定変更するのが漏れてしまったり、現状の監視設定がどうなっているのか不明で同じような監視設定が重複してしまうといった状態が起こっていました。
例えばRDSのCPU監視で単純に80%以上になったらアラート発報という設定をした場合、一時的なのかそれとも継続して発生しているのかということでアラートがノイズになる傾向がありました。

元々別の監視プロバイダーでアラート設定していましたが、WEB操作にて設定しており、なんの設定がされているか変更履歴などが見えにくい状態となっておりました。

どのような状態を目指していたか

アラートは発報したら何かしらのアクションが決まっているものをアラートとして定義し、時間経過によって解消するものはアラートとしてあげないように定義しました。

監視すべきリソースが変更された場合、変更されたことをトリガーとして監視設定の対象リソースも変更されることで、監視設定の変更漏れなどが防げる状態を目指していました。

• Datadog

アラーム設定を手動で行うとミスだったり、時間が膨大にかかったりするので、Infrastructure as Codeで設定できるかどうかという点

監視の設定で状態が一時的なのか継続して発生しているのか　ということをアラートとしてキャッチしたかったのでAmazon CloudWatch Alarmを選定しました。CPUが5分間隔で一時的に90%以上になるのは問題ないと考えていますが、 5分 × 3回で15分間90%以上となっているのはアラートとしたいという要件でAmazon CloudWatch Alarmの設定のシンプルさが決め手になりました。

改善したかった課題はどれくらい解決されたか

今まではアラートが多く重要なアラートも見逃してしまうこともあったのですが、アラートが整理されノイズが減ることでアラートをちゃんと見れるようになりました。

どのような成果が得られたか

アラート設定もコード管理することで似たようなアラート設定をコピー&ペーストした後に値の変更で完了するようになったので、アラート設定する作業工数削減にも効果が得られました。

Amazon CloudWatch Alarmへの移行にあたり、既存の監視設定と2重で発報しないように照らし合わせる作業が大変でした。

Amazon CloudWatch AlarmはAWSを利用していれば即座に利用できるため初期設定するケースが多いと思います。　ただ、最初のほうは頑張って設定したとしても開発者体験が良くないとシステムの変更などにより、意味のないアラートなどが生まれてきてしまう可能性があります。なので監視設計は初期設定で完了するのではなくシステムが継続する限り続く前提で運用を決めていったほうが良いと考えています。

現状はアラート監視設定と監視対象のリソースを別々で管理しています。監視対象リソースの変更が入った場合は動的に監視設定も変更するようにし、監視設定の負担を軽減しつつ、適正なアラート設定してある状態を保つようにしていきたいと考えてます。