EC2 Linux インスタンスがステータスチェックに合格できない場合のトラブルシューティング方法を教えてください。

簡単な説明

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

システムステータスチェック

システムステータスチェックはインスタンスの基盤となるハードウェアの問題を検出します。ネットワーク、ハードウェア、またはソフトウェアの問題のために基盤となるハードウェアが応答しない、または接続できない場合、システムステータスチェックは失敗します。

インスタンスステータスチェック

インスタンスが到達不能になっている場合、インスタンスステータスチェックは不合格となります。インスタンスのステータスチェックは、次の理由で不合格となる可能性があります。

• オペレーティングシステム (OS) が起動しない
• Amazon Elastic Block Store (Amazon EBS) ボリュームが正しくマウントされない
• CPU とメモリの枯渇
• カーネルパニック
• ネットワーク障害
• ルート EBS ボリュームパラメータのスロットリング

アタッチド EBS ステータスチェック

アタッチド EBS ステータスチェックは、インスタンスにアタッチされている EBS ボリュームがアクセス可能であり、I/O 操作を完了できるかどうかを監視します。詳細については、「アタッチド EBS ステータスチェック」を参照してください。

解決策

インスタンスステータスチェックまたはシステムステータスチェックが不合格となったかどうかを判断するには、インスタンスのステータスチェックメトリクスを確認します。

システムステータスチェックが不合格になった場合は、「EC2 Linux インスタンスがシステムステータスチェックに合格できなかった原因を教えてください」を参照してください。

インスタンスのステータスチェックが不合格となった場合は、インスタンスのシステムログを確認して失敗の原因を判断します。次に、以下のいずれかの解決オプションを選択して問題を解決します。

重要: 次の解決策の一部では、インスタンスを停止してから起動する必要が生じます。インスタンスを停止すると、インスタンスストアボリュームのデータは失われます。インスタンスに EBS ベースのボリュームがない場合は、そのインスタンスを停止する前にデータをバックアップしてください。なお、インスタンスのパブリック IPv4 アドレスは、インスタンスを停止して起動した後に変更される可能性があります。同じパブリック IPv4 アドレスを維持するには、Elastic IP アドレスを使用してください。詳細については、「Amazon EC2 インスタンスの停止と起動」を参照してください。

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 インスタンスを起動しようとすると緊急モードになる理由を知りたいです」および「オペレーティングシステムの問題が原因で、インスタンスステータスチェックに合格できない EC2 Linux インスタンスのトラブルシューティング方法を教えてください」を参照してください。

インスタンスタイプを Xen から Nitro ベースのインスタンスに変更すると、ボリュームをマウントできない場合があります。Nitro ベースのインスタンスでは、EBS ボリュームは NVMe ブロックデバイスとして公開されることが原因でマウントに失敗します。たとえば、デバイス名は /dev/nvme0n1、/dev/nvme1n1 という形式です。ブロックデバイスマッピングで指定したデバイス名は NVMe デバイス名に変更されます(例: /dev/nvme[0-26]n1)。

注: ブロックデバイスドライバーにより、ブロックデバイスマッピングで指定した順序とは異なる順序で NVMe デバイス名が割り当てられる場合があります。Nitro ベースのインスタンスでマウントエラーを回避するには、デバイス名にラベルまたは UUID を使用することをおすすめします。詳細については、「Amazon EBS ボリュームを使用できるようにする」を参照してください。

CPU とメモリの枯渇

CPU 使用率の増加

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

T2 または T3 インスタンスでは、Amazon CloudWatch CPU クレジットメトリクスを参照し、CPU クレジットがゼロまたはゼロに近いかどうかを判断します。CPU クレジットがゼロの場合、CPUUtilization メトリクスは、インスタンスのベースラインパフォーマンスが上限に達したことを示唆しています。たとえば、ベースラインパフォーマンスが 20% や 40% になっている可能性があります。CPU 使用率が 100% かそれに近い場合や、T2 インスタンスまたは T3 インスタンスが飽和状態に達した場合は、リソースの過剰使用が原因で、ステータスチェックは不合格と表示されます。

この問題のトラブルシューティング方法については、「リソースの過剰使用が原因で、EC2 Linux インスタンスがステータスチェックに合格できない場合のトラブルシューティング方法を教えてください」を参照してください。

ブロックデバイスのエラー、ソフトウェアのバグ、またはカーネルパニックが原因で、CPU 使用率が異常に急増する場合があります。CPU 使用率が 100% の場合は、システムログにブロックデバイスまたはメモリに問題があるエラーや、その他の異常なシステムエラーが記録されていないか確認してください。次に、インスタンスを再起動するか、停止後に起動します。

メモリ不足

メモリ負荷が高いと、インスタンスステータスチェックが不合格となる場合があります。次のログ抽出例では、OS のメモリが不足しており、OOM-killer が起動しています。このエラーを解決するには、最もメモリを消費しているプロセスを停止します。

[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 インスタンスのメモリとディスクに関するメトリクスは CloudWatch に送信されません。詳細については、「CloudWatch エージェントを使用してメトリクス、ログ、トレースを収集する」を参照してください。

メモリ不足の問題をトラブルシューティングして解決するには、インスタンスを大容量のインスタンスタイプにアップグレードします。または、インスタンスにスワップストレージを追加してメモリ負荷を軽減します。詳細については、「Amazon EC2 インスタンスにメモリを割り当て、スワップ領域として動作させる方法を教えてください」および、「ハードドライブ上のパーティションを使用してメモリを割り当て、Amazon EC2 インスタンスのスワップ領域として動作させる方法を教えてください」を参照してください。

ディスク容量不足エラー

システムログにディスク容量不足エラーが含まれている場合は、ルートデバイスに空き容量がないことが原因でインスタンスが緊急モードになっています。

システムログ例:

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

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

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

詳細については、「リソースの過剰使用が原因で、EC2 Linux インスタンスがステータスチェックに合格できない場合のトラブルシューティング方法を教えてください」および「ファイルシステムに空き領域がないことを示すエラーが発生した場合に、EBS ボリュームのサイズを増やす方法を教えてください」を参照してください。

カーネルパニック

カーネルパニックは、動作中にカーネルが致命的な内部エラーを検出したときに発生します。カーネルが正しくロードされない場合、エラーは OS の起動中に発生します。カーネルのロードに問題があるため、インスタンスを起動できません。

カーネルパニックのエラー出力例:

Linux version
2.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" エラーの解決方法を教えてください」および「更新が原因で EC2 インスタンスの再起動がブロックされた後に、既知の安定したカーネルに戻す方法を教えてください」を参照してください

ネットワーク障害

ネットワーク障害は、次の原因で発生する場合があります。

• cloud-init パッケージがインスタンスにインストールされていない。
• 起動時には、cloud-init パッケージを使用してネットワーク設定を更新します。

このエラーを修正し、cloud-init パッケージをインスタンスにインストールするには、ターミナルで次のコマンドを実行します。

Amazon、Amazon Linux 2、Amazon Linux 2023、RedHat OS:

sudo yum install cloud-init -y

Ubuntu、Debian OS:

sudo apt install cloud-init -y

MAC アドレスが設定ファイルにハードコードされている

ハードコーディングされた MAC アドレスが Linux 設定ファイルと udev 設定ファイルに含まれています。これらのファイルは、次の場所にあります。

• /etc/udev/rules.d/
• /etc/udev/rules.d/70-persistent-net.rules
• /etc/udev/rules.d/80-net-name-slot.rules

MAC アドレスがハードコードされていることが原因で発生したネットワークの問題を解決するには、該当するエントリまたは設定ファイルを削除してから、次のコマンドを実行します。

sudo mv /etc/udev/rules.d/70-persistent-net.rules /root/

設定ファイルを移動した後ネットワークサービスを再起動し、新しい MAC アドレスが割り当てられたことを確認します。

IP アドレスがネットワーク設定ファイルにハードコードされている

静的に設定した IP アドレスを持つインスタンスから Amazon マシンイメージ (AMI) を作成すると、設定ファイルにはハードコーディングされた IP アドレスが含まれます。このエラーを修正するには、ネットワークインターフェイスが DHCP を使用するように設定します。

注: 既存の AMI は更新できません。新しい AMI を作成するには、DHCP を使用するようにネットワークインターフェイスを設定する必要があります。

ENA または Intel 拡張ネットワークドライバーが欠けている

Elastic Network Adapter (ENA) または Intel 拡張ネットワークドライバーが欠けている場合の詳細については、「Amazon EC2 インスタンスでの拡張ネットワーク」を参照してください。

起動時に、ネットワークインターフェイスの名前が自動的に変更される

予測可能なネットワークインターフェイス名の変更を無効にするには、カーネルのコマンドラインに net.ifnames=0 を追加します。プレースホルダーを使用する場合は、ENA で拡張ネットワーク機能を有効にし、grub 設定ファイルを再構築または更新する必要があります。

ルート EBS ボリュームパラメータのスロットリング

ルート EBS ボリュームパラメータがスロットリングされると、インスタンスがアクセス不能になり、応答しなくなることが原因で、そのインスタンスがステータスチェックに合格できない場合があります。

EBS ボリュームの 1 秒あたりの I/O 操作数 (IOPS) またはスループットがプロビジョニングされた制限を超えると、スロットリングが発生する場合があります。EBS ボリュームのスロットリングによるパフォーマンスの低下が原因で、インスタンスが応答しなくなったり、アクセス不能になったりする場合があります。

EBS ボリュームのスロットリングに関する問題を解決するには、次の手順を実行します。

1. ボリュームキューの長さ、ボリュームの読み取り/書き込み操作、ボリュームの読み取り/書き込みバイト数などの CloudWatch メトリクスを監視、分析します。詳細については、「CloudWatch メトリクスを使用して、EBS ボリュームが実現する平均スループットと平均 IOPS 数を計算する方法を教えてください」を参照してください。
2. インスタンスを停止して起動するか、インスタンスを再起動すると、問題を一時的に解決できます。
3. EBS ボリュームの IOPS またはスループットを増やします。または、ワークロードにより適した EBS ボリュームタイプとサイズにアップグレードします。詳細については、「Amazon EBS ボリューム変更のリクエスト」を参照してください。

関連情報

Amazon EC2 Linux インスタンスがステータスチェックに合格できない場合のトラブルシューティング

EC2 Windows インスタンスがダウンしており、システムステータスチェックエラーが発生したりステータスチェックが 0/2 となったりする理由を知りたいです

インスタンスステータスチェックが失敗して EC2 Windows インスタンスがダウンするのはなぜですか?

ステータスチェックのタイプ