Amazon EC2 Linux インスタンスのステータスチェックに失敗する場合のトラブルシューティング方法を教えてください。

所要時間3分

Amazon Elastic Compute Cloud (Amazon EC2) Linux インスタンスが到達不能になっており、ステータスチェックに失敗しました。

簡単な説明

Amazon EC2 は、次の 3 種類のステータスチェックを使用して EC2 インスタンスの状態をモニタリングします。

システムステータスチェックは、インスタンスの基盤となるハードウェアの問題を検出します。
インスタンスステータスチェックは、インスタンスが到達可能かどうかを確認します。
注: インスタンスステータスチェックが失敗する場合は、オペレーティングシステム (OS) に問題があります。
アタッチされた Amazon Elastic Block Store (Amazon EBS) のステータスチェックは、インスタンスの Amazon EBS ボリュームが到達可能で I/O 操作を完了できるかどうかをモニタリングします。

解決策

失敗したステータスチェックを特定するには、インスタンスのステータスチェックメトリクスを表示します。

システムステータスチェックまたはアタッチされた EBS ステータスチェックの失敗をトラブルシューティングするには、「Amazon EC2 インスタンスがダウンし、システムのステータスチェックの失敗が発生した理由を教えてください」を参照してください。

インスタンスのステータスチェックが失敗した場合は、インスタンスのシステムログを確認して失敗の原因を判断します。次に、発生した問題に応じて、次のトラブルシューティング手順を実行します。

重要: 次の解決策の一部では、インスタンスを停止してから起動する必要があります。

インスタンスを停止して開始するように設定する

注: インスタンスを停止して開始する際、インスタンスのパブリック IP アドレスは変更されます。外部トラフィックをインスタンスにルーティングするには、パブリック IP アドレスではなく Elastic IP アドレスを使用することをお勧めします。Amazon Route 53 を使用している場合は、パブリック IP アドレスが変更された際、Route 53 の DNS レコードを更新する必要が生じる場合があります。停止して開始する操作はインスタンスの再起動とは異なります。詳細については、「EC2 インスタンスの停止および開始の動作」を参照してください。

インスタンスを停止して開始する前に、次の手順を実行してください。

インスタンスがインスタンスストアを使用している場合は、インスタンスストアのボリュームデータを永続ストレージに保存します。例えば、データを Amazon EBS ボリュームまたは Amazon Simple Storage Service (Amazon S3) バケットに保存できます。
重要: Amazon EC2 は、インスタンスを停止するとインスタンスストアのデータを削除します。
EBS ボリュームのスナップショットを作成します。問題が発生した場合は、スナップショットを使用してインスタンスを復元できます。
インスタンスを停止したときに誤ってインスタンスを削除しないように、Amazon EC2 Auto Scaling グループからインスタンスを一時的に削除します。
注: EC2 Auto Scaling は、スケールイン保護設定に基づいて、Auto Scaling グループ内の停止したインスタンスを削除する場合があります。Amazon EMR、AWS CloudFormation または AWS Elastic Beanstalk を使用して起動するインスタンスが、Auto Scaling グループに属している可能性があります。
インスタンスを停止したときに削除されないように、インスタンスのシャットダウン動作を [Stop] (停止) に設定してください。

起動に失敗する OS のトラブルシューティング

システムログにブートエラーが含まれている場合は、OS に問題があります。この問題のトラブルシューティング方法については、「オペレーティングシステムの問題のためにインスタンスのステータスチェックに失敗した EC2 Linux インスタンスのトラブルを解決するにはどうすればいいですか?」を参照してください。

正しくマウントされなかった EBS ボリュームのトラブルシューティング

マウントポイントの障害によりインスタンスのステータスチェックが失敗した場合は、次の例のような出力が表示されます。

[FAILED] Failed to mount /See 'systemctl status mnt-nvme0n1p1.mount' for details.
[DEPEND] Dependency failed for Local File Systems.

このエラーをトラブルシューティングするには、「オペレーティングシステムの問題のためにインスタンスのステータスチェックに失敗した EC2 Linux インスタンスのトラブルを解決するにはどうすればいいですか?」の「「Failed to mount」および「Dependency failed」」を参照してください。また、「EC2 Linux インスタンスのブートを試みると緊急モードになる理由を知りたいです」の「Dependency failed エラー」も参照してください。

Xen ベースのインスタンスタイプから AWS Nitro システム上に構築されたインスタンスに変更すると、ボリュームがマウントされないことがあります。Nitro インスタンスは EBS ボリュームを /dev/nvme0n1 や /dev/nvme1n1 などの NVMe ブロックデバイスとして公開します。ブロックデバイスマッピングで指定したデバイス名は、自動的に /dev/nvme[0-26]n1 形式に名前が変更されます。

注: ブロックデバイスドライバーは、NVMe デバイス名を異なる順序で割り当てる場合があります。

マウントの失敗を防ぐには、ボリュームのデバイス名の代わりに /etc/fstab にあるボリュームのファイルシステムラベルまたは UUID を使用してください。設定手順については、「Amazon EBS ボリュームを使用できるようにする」を参照してください。

CPU とメモリの使用量が多い場合のトラブルシューティング

CPU 使用率が高い

Amazon CloudWatch で CPUUtilization メトリクスが 100% またはそれに近い場合は、そのインスタンスにはカーネルを実行するのに十分なコンピューティング能力がありません。

T2 または T3 インスタンスの場合は、CPU クレジットメトリクスも確認してください。CPU クレジットが 0 の場合、CPUUtilization はインスタンスタイプのベースラインパフォーマンスレベルで停止します。例えば、ベースラインパフォーマンスが 20% または 40% の場合、インスタンスはそのレベルの CPU 使用率を超えません。

CPU 使用率が高い問題をトラブルシューティングするには、「Amazon EC2 Linux インスタンスの CPU 使用率が高い場合のトラブルシューティング方法を教えてください」を参照してください。

メモリ使用量の増加

メモリ負荷が高い場合、ログに次のエラーメッセージが表示されます。

"[115879.769795] Out of memory: kill process 20273 (httpd) score 1285879 or a child[115879.769795] Killed process 1917 (php-cgi) vsz:467184kB, anon-rss:101196kB, file-rss:204kB"

このエラーを解決するには、最もメモリを消費しているプロセスを停止します。実行中のすべてのプロセスが必要な場合は、インスタンスをより大きなインスタンスタイプにアップグレードしてください。または、インスタンスにスワップストレージを追加するか、ハードドライブのパーティションを作成して、メモリの負荷を軽減します。

その他のトラブルシューティング手順については、「EC2 Linux インスタンスでの、メモリ使用率増加に関する問題をトラブルシューティングする方法を教えてください」を参照してください。

フルディスクのトラブルシューティング

ルートデバイスがいっぱいになると、インスタンスは緊急モードになり、次の例のようなシステムログ出力が表示されます。

$: sudo service apache2 restart
Error: No space left on device

$: sudo /etc/init.d/mysql restart
[....] Restarting mysql (via systemctl):
mysql.service
Error: No space left on device

$: df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.7G  7.7G     0 100% /

この問題をトラブルシューティングするには、ボリュームのサイズを増やしてください。または、「リソースの過剰使用が原因で、EC2 Linux インスタンスがステータスチェックに合格できない場合のトラブルシューティング方法を教えてください」の「"No space left on device" エラーのトラブルシューティング」を参照してください。

カーネルパニックエラーのトラブルシューティング

カーネルパニックは、カーネルが操作中に内部エラーを検出した場合に発生します。カーネルがロードされない場合、インスタンスは起動できず、次の例のようなシステムログ出力が表示されます。

Linux version2.6.16-xenU (builder@xenbat.amazonsa) (gcc version 4.0.1 20050727 (Red Hat4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007
Kernel command
line:  root=/dev/sda1 ro 4
Registering block device major 8
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

この問題をトラブルシューティングするには、「EC2 インスタンスで発生する「Kernel panic - not syncing」エラーの解決方法を教えてください」を参照してください。または、既知の安定したカーネルに戻してください。

ネットワーク障害のトラブルシューティング

ネットワーク障害を特定してトラブルシューティングするには、「How do I troubleshoot OS-level network configuration issues on my Amazon EC2 Linux instance?」(Amazon EC2 Linux インスタンスの OS レベルのネットワーク設定の問題をトラブルシューティングする方法を教えてください) を参照してください。

調整されたルート EBS ボリュームのパフォーマンスのトラブルシューティング

EBS ボリュームが 1 秒あたりの入出力オペレーション (IOPS) またはスループットの制限を超えると、Amazon EC2 はボリュームを調整します。その結果、インスタンスはステータスチェックに失敗し、応答しなくなります。

Amazon EBS の CloudWatch メトリクスをモニタリングおよび分析して、予想されるボリューム、IOPS、またはスループットを把握します。

注: 調整されたボリュームを特定するには、時間が経っても変わらない IOPS またはスループットメトリクスを確認します。詳細については、「CloudWatch を使用して I/O 特性を監視する」を参照してください。

問題を一時的に解決するには、インスタンスを再起動または停止して起動し、IOPS とスループットを使用するプロセスを終了します。長期的な解決策としては、ワークロードにより適した EBS ボリュームタイプとサイズにアップグレードします。