EC2で動くサービスを監視するときは、まず「何が正常なら、サービスを利用できるのか」を分けて考えます。AWSの基盤が動き、OSが応答し、必要なストレージへ読み書きでき、その上でアプリケーションが正しい応答を返すことが必要です。
pingで確認できるのは、監視元から対象へのICMP通信です。pingが通っていても、Webサーバーのプロセスが停止していたり、業務処理が失敗していたりする可能性があります。そのため、EC2の死活監視では通信の確認に加えて、EC2の状態とアプリケーションの応答を確認する構成にします。
この記事では、監視する対象を整理したうえで、EC2のステータスチェックで分かること、追加で監視すること、異常をCloudWatchから通知する手順を説明します。
最初に、監視したい対象を分ける
例えば、EC2上のWebサイトが表示できなくなったとします。原因は、AWS側のホスト障害、OSの不調、ディスクへの読み書きの異常、Webアプリケーションの停止など、複数の場所に考えられます。利用者からの通信経路に問題がある場合もあります。
ひとつの監視結果だけでは、これらを区別できません。監視対象と手段を次のように対応させると、異常を検知した後の調査につながります。
| 確認したいこと | 監視手段 | 結果の読み方 |
|---|---|---|
| 監視元からEC2へ通信できるか | pingなどの経路からの監視 | 対象の状態と、監視元・通信経路の条件を確認する |
| AWSの基盤やEC2のOSに異常がないか | システム・インスタンスステータスチェック | 基盤側とインスタンス側を分けて調査する |
| 接続したEBSへ読み書きできるか | 接続されたEBSのステータスチェック | ストレージの到達性・I/Oの異常を確認する |
| アプリケーションが期待した応答を返すか | HTTP/HTTPSなどのアプリケーション監視 | 利用するサービスの応答を確認する |
ここからは、通信の確認だけでは分からないEC2内部の状態を、順に見ていきます。
基盤とOSの状態は、EC2のステータスチェックで確認する
アプリケーションが動く前提になるのが、EC2の基盤とOSの正常性です。EC2には、この状態を確認するシステムステータスチェックとインスタンスステータスチェックがあります。
システムステータスチェックは、EC2を動かしているAWS側のホストや基盤ネットワークを確認します。インスタンスステータスチェックは、個々のインスタンスのソフトウェアやネットワーク接続を確認します。後者では、EC2サービスがNICへARPリクエストを送ります。
この違いを知っておくと、異常通知を受けたときに「AWSの基盤側を確認するのか」「OSの設定や状態を調べるのか」という調査の入口を選べます。仕様はAWS公式のステータスチェック説明を参照してください。
ただし、これらが正常でも、アプリケーションの動作が正常とは限りません。基盤・OSの確認と、サービスの応答確認は分けて考えます。
EBSを使うサービスでは、ストレージの状態も確認する
OSが応答していても、アプリケーションが使うディスクへ読み書きできなければ、サービスは処理を続けられない場合があります。そこで、EBSを使う構成ではストレージも監視対象に加えます。
接続されたEBSのステータスチェックは、EBSへの到達性とI/Oを完了できるかを確認します。メトリクスはStatusCheckFailed_AttachedEBSで、Nitroインスタンスで利用できます。これはディスク使用率の監視とは異なる確認です。用途に応じて、容量や性能の監視も別に設計します。
つまり、EBSのチェックを加える理由は「サービスが必要とするストレージを使えるか」を確認するためです。基盤・OSが正常という結果だけで、この確認を済ませたことにはしません。
最後に、アプリケーションの応答を確認する
基盤・OS・ストレージの確認に加えて、利用者が使うサービスそのものを監視します。Webサイトなら、HTTP/HTTPSで指定したURLへアクセスし、期待する応答が返るかを確認する方法があります。
EC2には、明示的に設定するアプリケーションステータスチェックもあります。対象を関連付け、HTTPパスや正常とみなす応答コードを設定します。設定済みの基盤・OSのチェックだけでアプリケーションも監視されるわけではありません。EBSとアプリケーションのチェックについても、AWS公式資料で利用条件を確認してください。
監視用URLが正常でも、ログイン後の操作やデータ更新などが成功するとは限りません。サービスで必要な処理に合わせて、どこまで確認するかを決めます。また、利用者側の経路からの監視を組み合わせると、EC2内部の状態だけでは分からない通信の問題も切り分けやすくなります。
決めた監視対象の異常をCloudWatchから通知する
監視対象を決めたら、異常を担当者へ知らせる設定を作ります。ここでは、システムまたはインスタンスのステータスチェック失敗を、CloudWatchとSNSでメール通知する流れを示します。
使用するメトリクスはStatusCheckFailedです。これはシステムまたはインスタンスの失敗を示す値で、EBSやアプリケーションを含む全種類のチェックをまとめた値ではありません。それらも通知したい場合は、対応するメトリクスを監視対象にします。
- EC2コンソールで対象インスタンスを選び、ステータスチェックの画面からアラーム作成へ進みます。
- 通知を有効にしてSNSトピックを選びます。メールを登録した場合は、確認メールのリンクで購読を承認します。
- 監視するメトリクス、評価期間、失敗を通知する条件を設定します。
- 保存後、対象インスタンスID、通知先、購読の確認状態を見直します。
詳細はAWS公式のステータスチェック失敗アラーム作成手順を参照してください。異常の通知と、自動復旧などの操作は別の設定です。操作を自動化する場合は、業務への影響を検討してから設定します。
通知後の対応まで決めて、監視を運用する
メトリクスが欠落すると、アラームがINSUFFICIENT_DATAになる場合があります。AWSは、欠落をステータスチェック失敗ではなく欠落データとして扱うことを案内しています。特に停止・再起動などを自動実行する場合は、この設定を確認しましょう。
運用開始前には、通知先、何分の異常で対応するか、計画停止中の通知の扱いを決めます。通知を受けたら、失敗した監視対象を確認します。基盤・OS・ストレージのチェックは原因調査の入口になり、アプリケーションの監視はサービスの応答を判断する材料になります。
EC2の死活監視は、サービスに必要な各部分を監視し、その結果を組み合わせて判断できるように設計することが大切です。
ALBを使うサービスで応答の遅さも調べたい場合は、ALBの応答時間をアクセスログから測る方法を参照してください。サービスが応答するかの確認に加え、どの区間で時間がかかるかを整理できます。
