Wie behebe ich Fehler bei der Statusüberprüfung für meine EC2-Linux-Instance?

Kurzbeschreibung

Amazon EC2 verwendet drei Statusprüfungen, um den Zustand von EC2-Instances zu überwachen.

Systemstatusüberprüfungen

Die Systemstatusprüfung erkennt Probleme mit der zugrunde liegenden Hardware einer Instanz. Wenn die zugrunde liegende Hardware aufgrund von Netzwerk-, Hardware- oder Softwareproblemen nicht reagiert oder nicht erreichbar ist, schlägt die Systemstatusprüfung fehl.

Überprüfung des Instancestatus

Eine Instance-Statusprüfung schlägt fehl, wenn du die Instance nicht erreichen kannst. Instance-Statusprüfungen können aus den folgenden Gründen fehlschlagen:

• Das Betriebssystem (OS) kann nicht gestartet werden
• Die Amazon Elastic Block Store (Amazon EBS)-Volumes können nicht korrekt bereitgestellt werden
• Die CPU und der Speicher sind erschöpft
• Kernel Panic
• Netzwerkausfall
• Drosselung der EBS-Root-Volume-Parameter

Angehängte EBS-Statusprüfungen

Die angehängten EBS-Statusprüfungen überwachen, ob die EBS-Volumes, die an eine Instance angehängt sind, erreichbar sind und E/A-Operationen durchführen können. Weitere Informationen findest du unter Angehängte EBS-Statusprüfungen.

Lösung

Ob die Instance-Statusprüfung oder die Systemstatusprüfung fehlgeschlagen ist, kannst du in den Statusprüfungsmetriken der Instance nachlesen.

Wenn die Systemstatusprüfung fehlgeschlagen ist, siehe Warum hat meine EC2-Linux Instance eine Systemstatusprüfung nicht bestanden?

Wenn die Instance-Statusprüfung fehlgeschlagen ist, überprüfe die Systemprotokolle der Instance, um die Ursache des Fehlers zu erkennen. Wähle dann eine der folgenden Lösungsoptionen, um das Problem zu beheben.

Wichtig: Bei einigen der folgenden Lösungen musst du eine Instance beenden und dann starten. Daten auf einem Instance-Speicher-Volume gehen verloren, wenn du die Instance beendest. Wenn die Instance keine EBS-gesicherten Volumes enthält, sichere die Daten, bevor du die Instance beendest. Außerdem kann sich die öffentliche IPv4-Adresse der Instance ändern, nachdem du die Instance beendet und gestartet hast. Verwende eine Elastic IP-Adresse, um dieselbe öffentliche IPv4-Adresse beizubehalten. Weitere Informationen findest du unter Stoppen und Starten von Amazon EC2-Instances.

Das Betriebssystem kann nicht gestartet werden

Wenn die Systemprotokolle Startfehler enthalten, findest du weitere Informationen unter Wie behebe ich eine EC2-Linux-Instance, die die Instance-Statusprüfung aufgrund von Betriebssystemproblemen nicht bestanden hat?

Die EBS-Volumes können nicht korrekt gemountet werden

Ein Ausfall des Bereitstellungspunkts kann dazu führen, dass die Überprüfung des Instance-Status fehlschlägt.

Beispiel für einen Ausfall der Mount Points-Ausgabe:

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

Weitere Informationen zu diesen Fehlern findest du unter Warum wechselt meine EC2-Linux-Instance in den Notfallmodus, wenn ich versuche, sie zu starten? Siehe auch Wie behebe ich eine EC2-Linux-Instance, die die Instance-Statusprüfung aufgrund von Betriebssystemproblemen nicht bestanden hat?

Wenn du einen Instance-Typ von einer Xen- zu einer Nitro-basierten Instance wechselst, könnte der Volume-Mount möglicherweise fehlschlagen. Ein Mount-Fehler tritt auf, weil EBS-Volumes als NVMe-Blockgeräte auf Nitro-basierten Instances verfügbar gemacht werden. Die Gerätenamen lauten zum Beispiel /dev/nvme0n1 und /dev/nvme1n1. Gerätenamen, die du in einer Blockgerät-Zuweisung angibst, werden in NVMe-Gerätenamen umbenannt. Zum Beispiel /dev/nvme\ [0-26] n1.

Hinweis: Der Blockgerätetreiber weist die NVMe-Gerätenamen möglicherweise in einer anderen Reihenfolge zu als in der Reihenfolge, die du in der Blockgerät-Zuweisung angibst. Um Bereitstellungsfehler auf Nitro-basierten Instances zu vermeiden, empfiehlt es sich, entweder ein Label oder eine UUID für Gerätenamen zu verwenden. Weitere Informationen findest du unter Bereitstellen eines Amazon EBS-Volumes für die Verwendung.

Die CPU und der Speicher sind erschöpft

Hohe CPU-Auslastung

Wenn die CPUUtilization-Metrik bei oder nahe 100 % liegt, verfügt die Instance nicht über genügend Rechenkapazität, um den Kernel auszuführen.

Überprüfe für T2- oder T3-Instances anhand der Amazon CloudWatch-CPU-Kreditkennzahlen, ob die CPU-Gutschriften bei oder nahe Null liegen. Wenn die CPU-Guthaben bei Null liegen, zeigt der CPUUtilization-Messwert ein Sättigungsplateau bei der Basisleistung für die Instance an. Die Grundleistung kann beispielsweise 20 % oder 40 % betragen. Wenn die CPU-Auslastung bei oder nahe 100 % liegt oder T2- oder T3-Instances ein Sättigungsplateau erreicht haben, wird die Statusüberprüfung aufgrund einer Ressourcenüberlastung als fehlgeschlagen angezeigt.

Informationen zur Behebung dieses Problems findest du unter Wie behebe ich Fehler bei einer EC2-Linux-Instance, bei der eine Statusprüfung aufgrund einer übermäßigen Ressourcennutzung fehlschlägt?

Blockgerätfehler, Softwarefehler oder Kernel-Panik können zu einem ungewöhnlichen Anstieg der CPU-Auslastung führen. Wenn die CPU-Auslastung bei 100% liegt, überprüfe die Systemprotokolle auf Blockgeräte- oder Speicherfehler oder andere ungewöhnliche Systemfehler. Starte dann die Instance neu oder beende sie und starte sie.

Nicht genügend Speicher

Ein hoher Speicherdruck kann dazu führen, dass die Instance-Statusprüfung fehlschlägt. Im folgenden Beispielprotokollauszug hat das Betriebssystem nicht genügend Speicher und der OOM-killer wird gestartet. Um diesen Fehler zu beheben, beende den Prozess, der den meisten Speicher verbraucht.

[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

Standardmäßig werden Speicher- und Festplattenmetriken der EC2-Instance nicht an CloudWatch gesendet. Weitere Informationen findest du unter Metriken, Protokolle und Traces mit dem CloudWatch-Agent erfassen.

Um das Problem mit unzureichendem Speicher zu beheben und zu lösen, führe ein Upgrade der Instance auf einen größeren Instance-Typ durch. Oder füge der Instance Swap-Speicher hinzu, um den Speicherdruck zu verringern. Weitere Informationen findest du unter Wie weise ich Speicher zu, damit er als Swap-Datei in einer Amazon EC2-Instance funktioniert? Siehe auch Wie ordne ich Speicher zu, der als Auslagerungsspeicher auf einer Amazon EC2-Instance dient, indem ich eine Partition auf meiner Festplatte verwende?

Fehler bei voller Festplatte

Wenn die Systemprotokolle Fehler enthalten, dass die Festplatte voll ist, befindet sich die Instance aufgrund eines vollen Root-Geräts im Notfallmodus.

Beispiel für ein Systemprotokoll:

$: 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% /

Weitere Informationen findest du unter Wie behebe ich Fehler bei einer EC2-Linux-Instance, die eine Statusprüfung aufgrund einer übermäßigen Ressourcennutzung nicht besteht? Siehe auch Wie erhöhe ich die Größe meines EBS-Volumes, wenn ich die Fehlermeldung erhalte, dass auf meinem Dateisystem kein Speicherplatz mehr verfügbar ist?

Kernel Panic

Eine Kernel-Panik tritt auf, wenn der Kernel während des Betriebs einen internen schwerwiegenden Fehler feststellt. Wenn der Kernel nicht richtig geladen wird, tritt der Fehler während des Betriebssystemstarts auf. Ein Fehler beim Laden des Kernels führt dazu, dass der Instance-Start fehlschlägt.

Beispiel für eine Kernel-Panik-Fehlerausgabe:

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)

Weitere Informationen findest du unter Wie behebe ich den Fehler „Kernel panic − not sync“ in meiner EC2-Instance? Siehe auch Wie kehre ich zu einem bekannten stabilen Kernel zurück, nachdem ein Update den Neustart meiner EC2-Instance blockiert hat?

Netzwerkausfall

Dein Netzwerk kann aus den folgenden Gründen ausfallen:

• Das cloud-init-Paket ist nicht auf der Instance installiert.
• Das Cloud-Init-Paket wird verwendet, um Netzwerkkonfigurationen beim Start zu aktualisieren.

Um diesen Fehler zu beheben und das cloud-init-Paket auf deiner Instance zu installieren, führe den folgenden Befehl im Terminal aus.

Amazon, Amazon Linux 2, Amazon Linux 2023 oder RedHat OS:

sudo yum install cloud-init -y

Ubuntu oder Debian OS:

sudo apt install cloud-init -y

Die MAC-Adresse ist in einer Konfigurationsdatei fest codiert

Hartcodierte MAC-Adressen befinden sich in den Linux-Konfigurationsdateien und den Udev-Konfigurationsdateien. Du kannst diese Dateien an den folgenden Orten finden:

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

Um Netzwerkprobleme zu beheben, die durch eine fest kodierte MAC-Adresse verursacht werden, entferne die Einträge oder Konfigurationsdateien und führe dann den folgenden Befehl aus:

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

Nachdem du die Konfigurationsdatei verschoben hast, starte den Netzwerkdienst neu, um sicherzustellen, dass du eine neue MAC-Adresse erhältst.

Die IP-Adresse ist in einer Netzwerkkonfigurationsdatei fest codiert

Wenn du ein Amazon Machine Image (AMI) aus einer Instance mit einer statisch konfigurierten IP-Adresse erstellst, enthält die Konfigurationsdatei eine hartcodierte IP-Adresse. Um diesen Fehler zu korrigieren, stelle deine Netzwerkschnittstelle so ein, dass sie DHCP verwendet.

Hinweis: Du kannst keine AMIs aktualisieren, die bereits existieren. Du musst die Netzwerkschnittstelle so einrichten, dass sie DHCP verwendet, bevor du ein neues AMI erstellest.

Die ENA- oder Intel-erweiterten Netzwerktreiber fehlen

Weitere Informationen zu fehlenden Elastic Network Adapters (ENAs) oder Intel-erweiterten Netzwerktreibern findest du unter Erweitertes Netzwerk auf Amazon EC2-Instances.

Die Netzwerkschnittstelle wird beim Start automatisch umbenannt

Um die vorhersehbare Umbenennung von Netzwerkschnittstellen zu deaktivieren, füge net.ifnames=0 in die Kernel-Befehlszeile ein. Um den Platzhalter zu verwenden, musst du das erweiterte Netzwerk mit der ENA aktivieren und die grub-Konfigurationsdatei neu erstellen oder aktualisieren.

Drosselung der EBS-Root-Volume-Parameter

Wenn die EBS-Root-Volume-Parameter gedrosselt werden, besteht die Instance möglicherweise nicht bei Statusprüfungen, da die Instance nicht mehr erreichbar ist und nicht mehr reagiert.

Drosselung kann auftreten, wenn die E/A-Operationen pro Sekunde (IOPS) oder der Durchsatz eines EBS-Volumes die bereits bereitgestellten Grenzwerte überschreiten. Die Instance reagiert möglicherweise nicht mehr oder ist aufgrund der Leistungseinbußen aufgrund der EBS-Volume-Drosselung nicht mehr erreichbar.

Gehe wie folgt vor, um Probleme mit der EBS-Volume-Drosselung zu beheben:

1. Überwache und analysiere CloudWatch-Metriken wie die Länge der Volume-Warteschlange, Volume-Lese-/Schreibvorgänge und Volume-Lese-/Schreib-Bytes. Weitere Informationen findest du unter Wie verwende ich die CloudWatch-Metriken, um den durchschnittlichen Durchsatz und die durchschnittliche Anzahl der IOPS zu berechnen, die mein EBS-Volume liefert?
2. Stoppe und starte die Instance oder starte sie neu, um das Problem vorübergehend zu lösen.
3. Stelle mehr IOPS oder einen höheren Durchsatz des EBS-Volumes bereit. Oder führe ein Upgrade auf einen EBS-Volume-Typ und eine EBS-Größe durch, die besser zur Workload passen. Weitere Informationen findest du unter Anfragen zu Änderungen des Amazon EBS-Volume.

Ähnliche Informationen

Fehlerbehebung bei Amazon EC2-Linux-Instances mit fehlgeschlagenen Statusprüfungen

Warum ist meine EC2-Windows-Instance aufgrund eines Fehlers bei der Systemstatusprüfung oder der Statusprüfung 0/2 ausgefallen?

Warum ist meine EC2-Windows-Instance aufgrund einer fehlgeschlagenen Instanzstatusprüfung ausgefallen?

Arten von Statusprüfungen