前回の記事でオンプレサーバーのメトリクスをCloudWatchで見れるように設定しました。
本記事ではそのメトリクスを使って以下を実現したいと思います。
- 「CloudWatch > ダッシュボード」を作成し、サーバー負荷を即座に把握する
- 「CloudWatch > アラーム」を作成し、異常を検知したらSlack通知する
ダッシュボード作成
最終的に以下のようなメトリクス（CPU使用率、メモリ使用率、ディスク使用率）をサーバーごとに確認できるダッシュボードが作成したいです。
例えば、各サーバーの「CPU使用率」を表示したい場合、正常にオンプレサーバーからCloudWatchにメトリクスが飛ばせていたら「CWAgent > cpu,host > cpu_usage_user」にサーバー（host名）毎にデータが蓄積されているはずです。（そのためサーバーを構築する際は必ずホスト名を設定しておきましょう）
あとは表示させたいホスト名を選択して表示設定するだけです。
サーバー負荷が高くなった際はこのダッシュボードを見ればどのサーバーの何が異常なのかが判断できるはずです。
アラーム設定（CPU使用率）
続いてアラーム設定ですが、いずれかのサーバーのCPU使用率が70%を超えた場合にCloudWatchアラームで検知し、Slack通知を送信したいです。
サーバーごとに１つずつアラームを設定することもできますが、管理するサーバーが増えるとアラーム設定が大変です、その場合は「マルチソースクエリ」で対象サーバー群のCPU使用率の最大値を取得し、その値を判断してアラームを設定します。
以下が「マルチソースクエリ」の例になります
SQL形式でも指定が可能です。
WHERE句で特定のhostだけ除外することも可能でしが IN や LIKE は使えないようです。。。
こうすることで監視対象サーバーが複数あった場合でも「いずれかが閾値を超えたら通知」が簡単に実装できます。
以下が最終的なアラーム設定例になります。
通知設定についてはAmazon SNSでトピックを作成しておいて、Slackチャンネルにメール通知するのが一番簡単かなと思いますが設定方法については割愛します。
基本的に、メモリ使用率やディスク使用率も同じ手順で設定が可能です。
アラーム設定（エラーログ）
続いて、アプリケーションの運用保守に欠かせない「エラーログ検知」の設定になります、特にリリース直後などユーザーの想定外の操作や登録データによって発生するバグ、つまりExceptionをいち早く検知し修正することが求められます。
まず前回の記事でアプリケーションのログがCloudWatch飛んでいてロググループが作られているはずで、ロググループの詳細画面にて「メトリクスフィルター」を事前に作成しておきます。
以下はエラーログに出力される “:ERROR” を完全一致で検知する例になります。
次の画面では検知した値を格納するメトリクスを設定しますが、メトリクス名前空間はプロジェクト名を共通で設定し、メトリクス名には例えば api_error_log_detection のようにアプリケーションが識別可能な名前をつけるのが良いとおもいます。
あとはこのメトリクスを元にアラームを設定するだけです、値が1以上で異常と判断して同じくSlack通知するようにします。
今回はオンプレサーバーの監視をCloudWatchで実践しましたが、監視サーバー自体の費用やその構築コストがかからない分、CloudWatchのコストには注意しないと行けないですが、使い慣れたCloudWatchに集約できる分メリットはそれなりにあるのではないかと思っています。
