Amazon EC2 インスタンスのステータスチェック
インスタンスのステータスのモニタリングではインスタンスによるアプリケーションの実行を妨げる可能性のある問題を Amazon EC2 が検出したかどうかをすばやく判断できます。Amazon EC2 は稼働中のすべての EC2 インスタンスに対して自動チェックを実行して、ハードウェアおよびソフトウェアの問題を特定します。これらのステータスチェックの結果を表示して、具体的で検出可能な問題を識別できます。このイベントステータスデータは各インスタンス (pending、running、stopping) の状態に関して Amazon EC2 が既に提供している情報と、Amazon CloudWatch が監視している使用状況メトリクス (CPU 使用率、ネットワークトラフィック、ディスクアクティビティ) を補足するものです。
ステータスチェックは 1 分ごとに実行され、それぞれ成功または失敗のステータスが返ります。すべてのチェックが成功すると、インスタンス全体のステータスが OK になります。1つ以上のチェックが失敗すると、全体のステータスが impaired になります。ステータスチェックは Amazon EC2 に組み込まれています。そのため、無効にしたり、削除したりすることはできません。
ステータスチェックに失敗すると、ステータスチェックの対応する CloudWatch メトリクスは増加します。詳細についてはステータスチェックメトリクスを参照してください。このようなメトリクスを使用して、ステータスチェックの結果に基づいてトリガーされる CloudWatch アラームを作成することができます。例えば、特定のインスタンスでステータスチェックが失敗したときに警告するアラームを作成できます。詳細についてはステータスチェックに失敗した Amazon EC2 インスタンスの CloudWatch アラームの作成を参照してください。
また、Amazon EC2 インスタンスをモニタリングし、基になる問題によりインスタンスが正常に機能しなくなった場合に、自動的にインスタンスを復旧する Amazon CloudWatch アラームを作成できます。詳細についてはインスタンスの自動復旧を参照してください。
コンテンツ
ステータスチェックのタイプ
ステータスチェックには 3 種類あります。
システムステータスのチェック
システムステータスチェックはインスタンスが実行されている AWS システムをモニタリングします。これらのチェックでは修復には AWS の関与が必要なインスタンスの基盤の問題が検出されます。システムステータスチェックが失敗した場合、AWS が問題を解決するのを待つか、自分で解決できるかを選択できます。Amazon EBS でバックアップされたインスタンスの場合はインスタンスを自分で停止および起動することができます。通常、インスタンスは新しいホストに移行されます。Linux インスタンスストアによってサポートされているインスタンスの場合、インスタンスを終了して置き換えることができます。Windows インスタンスの場合、ルートボリュームは Amazon EBS ボリュームであることが必要です。インスタンスストアはルートボリュームではサポートされません。インスタンスストアボリュームは短期のものであり、インスタンスが停止するとすべてのデータが失われることに注意してください。
システムステータスチェックの失敗の原因となる問題の例を次に示します。
-
ネットワーク接続の喪失
-
システム電源の喪失
-
物理ホストのソフトウェアの問題
-
ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題
システムステータスチェックが失敗した場合、StatusCheckFailed_System メトリクスをインクリメントします。
ベアメタルインスタンス
ベアメタルインスタンス上のオペレーティングシステムから再起動を実行すると、システムステータスチェックが一時的に失敗ステータスを返すことがあります。インスタンスが使用可能になると、システムステータスチェックからは成功ステータスが返されます。
インスタンスステータスのチェック
[インスタンスステータスのチェック] 個々のインスタンスのソフトウェアとネットワークの設定をモニタリングします。Amazon EC2 はネットワークインターフェイス (NIC) にアドレス解決プロトコル (ARP) リクエストを送信することでインスタンスのヘルスをチェックします。これらのチェックではユーザーが関与して修復する必要のある問題が検出されます。インスタンスステータスチェックが失敗した場合は通常、自分自身で (例えば、インスタンスを再起動する、インスタンス設定を変更するなどによって) 問題に対処する必要があります。
注記
ネットワーク設定に systemd-networkd を使用する最近の Linux ディストリビューションではヘルスチェックに関するレポートが以前のディストリビューションとは異なる場合があります。起動プロセス中、このタイプのネットワークはインスタンスのヘルスにも影響する可能性のある他のスタートアップタスクよりも早く起動し、また早く終了する可能性もあります。ネットワークの可用性に依存するステータスチェックでは他のタスクが完了する前に正常なステータスをレポートできます。
インスタンスステータスチェックの失敗の原因となる問題の例を次に示します。
-
失敗したシステムステータスチェック
-
正しくないネットワークまたは起動設定
-
メモリの枯渇
-
破損したファイルシステム
-
互換性のないカーネル
-
再起動中、インスタンスのステータスチェックはインスタンスが再び使用可能になるまで失敗を報告します。
インスタンスのステータスチェックが失敗した場合、StatusCheckFailed_Instance メトリクスをインクリメントします。
ベアメタルインスタンス
ベアメタルインスタンス上のオペレーティングシステムから再起動を実行すると、インスタンスのステータスチェックが一時的に失敗ステータスを返すことがあります。インスタンスが使用可能になると、インスタンスステータスチェックからは成功ステータスが返されます。
アタッチ済みの EBS ステータスチェック
アタッチ済みの EBS ステータスチェックはインスタンスにアタッチされている Amazon EBS ボリュームが到達可能かどうか、および I/O 操作を完了できるかどうかをモニタリングします。StatusCheckFailed_AttachedEBS メトリクスはインスタンスにアタッチされている 1 つ以上の EBS ボリュームが I/O 操作を完了できない場合に障害が発生することを示すバイナリ値です。これらのステータスチェックはコンピューティングまたは Amazon EBS インフラストラクチャの根本的な問題を検出します。アタッチ済みの EBS ステータスチェックメトリクスが失敗した場合はAWS を待って問題を解決するか、影響を受けたボリュームの置き換えやインスタンスの停止および再起動などのアクションを取ることができます。
アタッチ済みの EBS ステータスチェックが失敗する原因となる問題の例を次に示します。
-
EBS ボリュームの基盤となるストレージサブシステムのハードウェアまたはソフトウェアの問題
-
EBS ボリュームの到達可能性に影響する、物理ホスト上のハードウェアの問題
-
インスタンスと EBS ボリューム間の接続に関する問題
StatusCheckFailed_AttachedEBS メトリクスを使うことで、ワークロードの耐障害性を向上できます。このメトリクスを使用して、ステータスチェックの結果に基づいてトリガーされる Amazon CloudWatch アラームを作成することができます。例えば、長期にわたる影響を検出した場合はセカンダリインスタンスまたはアベイラビリティーゾーンにフェイルオーバーできます。またはEBS CloudWatch メトリクスを使用してアタッチされた各ボリュームの I/O パフォーマンスをモニタリングし、障害のあるボリュームを検出して置き換えることもできます。ワークロードがインスタンスに接続されている EBS ボリュームに対しても I/O を発生させておらず、EBS ステータスチェックで障害が判明した場合は、インスタンスを停止して起動し、新しいホストに移動できます。これにより、EBS ボリュームの到達可能性に影響を与えている、基盤となるホストの問題を解決できます。詳細については「Amazon EBS の Amazon CloudWatch メトリクス」を参照してください。
アタッチ済みの EBS ステータスチェックの失敗を検出し、影響を受けたインスタンスを新しいインスタンスに置き換えるように Amazon EC2 Auto Scaling グループを設定することもできます。詳細については「Amazon EC2 Auto Scaling ユーザーガイド」の「障害のあるAmazon EBS ボリュームを持つ Auto Scaling インスタンスの監視と置き換え」を参照してください。
注記
アタッチ済みの EBS ステータスチェックメトリクスはNitro インスタンスでのみ使用できます。
