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

Lesedauer: 7 Minute

Meine Amazon Elastic Compute Cloud (Amazon EC2)-Linux-Instance ist nicht erreichbar und besteht ihre Statusprüfungen nicht.

Kurzbeschreibung

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

Systemstatusprüfungen, die Probleme mit der zugrunde liegenden Hardware einer Instance erkennen
Instance-Statusprüfungen, die überprüfen, ob die Instance erreichbar ist
Hinweis: Fehler bei der Instance-Statusprüfung treten auf, wenn es Probleme mit dem Betriebssystem gibt.
Angefügte Amazon Elastic Block Store (Amazon EBS)-Statusprüfungen, die überwachen, ob die Amazon-EBS-Volumes der Instance erreichbar sind und E/A-Vorgänge abschließen können.

Lösung

Um die fehlgeschlagene Statusprüfung zu identifizieren, sieh dir die Statusprüfungsmetriken der Instance an.

Informationen zur Behebung von Fehlern bei der Systemstatusprüfung oder der angefügten EBS-Statusprüfung findest du unter How do I troubleshoot status check failures on my Amazon EC2 instance? (Wie behebe ich Fehler bei der Statusprüfung auf meiner Amazon-EC2-Instance?)

Wenn die Instance-Statusprüfung fehlgeschlagen ist, überprüfe die Systemprotokolle der Instance, um die Ursache des Fehlers zu finden. Ergreife anschließend je nach dem Problem, auf das du stößt, die folgenden Maßnahmen.

Wichtig: Bei einigen der folgenden Lösungen musst du die Instance anhalten und starten.

Die Instance für einen Stopp und Start konfigurieren

Hinweis: Wenn du eine Instance anhältst und startest, ändert sich die öffentliche IP-Adresse der Instance. Es empfiehlt sich, beim Weiterleiten von externem Datenverkehr an die Instance eine Elastic IP-Adresse anstelle einer öffentlichen IP-Adresse zu verwenden. Wenn du Amazon Route 53 verwendest, musst du möglicherweise die Route-53-DNS-Datensätze aktualisieren, wenn sich die öffentliche IP-Adresse ändert. Ein Stopp und Start unterscheidet sich von einem Instance-Neustart. Weitere Informationen findest du unter So funktioniert das Anhalten und Starten von EC2-Instances.

Bevor du die Instance anhältst und startest, gehe wie folgt vor:

Wenn deine Instance einen Instance-Speicher verwendet, speichere die Volume-Daten im Instance-Speicher im persistenten Speicher. Zum Beispiel kannst du die Daten in Amazon-EBS-Volumes oder Amazon Simple Storage Service (Amazon S3)-Buckets speichern.
Wichtig: Amazon EC2 löscht Instance-Speicherdaten, wenn du die Instance anhältst.
Erstelle einen Snapshot des EBS-Volumes. Wenn Probleme auftreten, kannst du den Snapshot verwenden, um deine Instance wiederherzustellen.
Entferne die Instance vorübergehend aus ihrer Amazon-EC2-Auto-Scaling-Gruppe, damit du die Instance beim Anhalten nicht versehentlich beendest.
Hinweis: EC2 Auto Scaling kann angehaltene Instances in einer Auto-Scaling-Gruppe basierend auf deinen Einstellungen für den Abskalierungsschutz beenden. Instances, die du mit Amazon EMR, AWS CloudFormation oder AWS Elastic Beanstalk startest, sind möglicherweise Teil einer Auto-Scaling-Gruppe.
Stelle das Verhalten beim Herunterfahren der Instance auf Stop (Stopp) ein, um sicherzustellen, dass die Instance nicht beendet wird, wenn du sie anhältst.

Problembehandlung bei einem Betriebssystem, das nicht gestartet werden kann

Wenn die Systemprotokolle Startfehler enthalten, liegen Betriebssystemprobleme vor. Informationen zur Behebung dieses Problems findest du unter How do I troubleshoot an EC2 Linux instance that failed the instance status check because of OS issues? (Wie behebe ich Probleme mit einer EC2-Linux-Instance, bei der die Instance-Statusprüfung aufgrund von Betriebssystemproblemen fehlschlägt?)

Problembehandlung bei EBS-Volumes, die nicht korrekt eingebunden wurden

Wenn aufgrund eines Einbindepunkt-Fehlers die Instance-Statusprüfung fehlgeschlagen ist, erhältst du eine Ausgabe, die dem folgenden Beispiel ähnelt:

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

Informationen zur Behebung dieses Fehlers findest du unter Troubleshoot "Failed to mount" or "Dependency failed" (Problembehandlung bei „Failed to mount“ oder „Dependency failed“) unter How do I troubleshoot an EC2 Linux instance that failed the instance status check because of OS issues? (Wie behebe ich Probleme mit einer EC2-Linux-Instance, bei der die Instance-Statusprüfung aufgrund von Betriebssystemproblemen fehlschlägt?) Weitere Informationen findest du auch unter Fehler „Dependency failed“ unter Warum wechselt meine EC2-Linux-Instance in den Notfallmodus, wenn ich versuche, sie zu starten?

Wenn du von einem Xen-basierten Instance-Typ zu einer Instance wechselst, die auf dem AWS Nitro System basiert, können die Volumes möglicherweise nicht eingebunden werden. Nitro-Instances stellen EBS-Volumes als NVMe-Blockgeräte bereit, z. B. /dev/nvme0n1 oder /dev/nvme1n1. Gerätenamen, die du in einer Blockgerät-Zuweisung angibst, werden automatisch in das Format /dev/nvme[0-26]n1 umbenannt.

Hinweis: Der Blockgerätetreiber weist die NVMe-Gerätenamen möglicherweise in einer anderen Reihenfolge zu.

Um Einbindefehler zu vermeiden, verwende die Dateisystembezeichnung oder die UUID des Volumes in /etc/fstab anstelle der Gerätenamen des Volumes. Konfigurationsschritte findest du unter Bereitstellen eines Amazon EBS-Volumes für die Verwendung.

Problembehandlung bei hohem CPU- und Speicherbedarf

Hohe CPU-Auslastung

Wenn die CPUUtilization-Metrik in Amazon Cloudwatch 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 auch die CPU-Guthabenmetriken. Wenn das CPU-Guthaben bei Null liegt, stoppt CPUUtilization auf dem Basisleistungsniveau für den Instance-Typ. Wenn die Basisleistung beispielsweise 20 % oder 40 % beträgt, überschreitet die Instance diese CPU-Auslastung nicht.

Informationen zur Problembehandlung bei hoher CPU-Auslastung findest du unter Wie behebe ich eine hohe CPU-Auslastung auf einer Amazon-EC2-Linux-Instance?

Hohe Speicherauslastung

Wenn der Speicherdruck hoch ist, wird in den Protokollen die folgende Fehlermeldung angezeigt:

"[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"

Um dieses Problem zu beheben, stoppe den Prozess, der den meisten Speicher verbraucht. Wenn du alle laufenden Prozesse benötigst, aktualisiere die Instance auf einen größeren Instance-Typ. Oder füge der Instance Swap-Speicher hinzu oder partitioniere deine Festplatte, um den Speicherdruck zu verringern.

Weitere Schritte zur Problembehandlung findest du unter Wie behebe ich Probleme mit hoher Speicherauslastung auf meiner EC2-Linux-Instance?

Problembehandlung bei einer vollen Festplatte

Wenn das Root-Gerät voll ist, wechselt die Instance in den Notfallmodus und du erhältst eine Systemprotokollausgabe ähnlich dem folgenden Beispiel:

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

Erhöhe die Größe deines Volumes, um dieses Problem zu beheben. Oder siehe Beheben des Fehlers „No space left on device“ unter Wie behebe ich Probleme mit einer EC2-Linux-Instance, die eine Statusüberprüfung aufgrund einer Ressourcenüberlastung nicht besteht?

Behebung eines Kernel-Panik-Fehlers

Kernel-Panik tritt auf, wenn der Kernel während der Operation einen internen Fehler entdeckt. Wenn der Kernel nicht geladen wird, kann die Instance nicht gestartet werden und du erhältst eine Systemprotokollausgabe ähnlich dem folgenden Beispiel:

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)

Informationen zur Behebung dieses Problems findest du unter Wie behebe ich den Fehler „Kernel panic - not syncing“ in meiner EC2-Instance? Oder kehre zu einem bekannten stabilen Kernel zurück.

Netzwerkfehler beheben

Informationen zur Identifizierung und Behebung von Netzwerkfehlern findest du unter How do I troubleshoot OS-level network configuration issues on my Amazon EC2 Linux instance? (Wie behebe ich Probleme mit der Netzwerkkonfiguration auf Betriebssystemebene auf meiner Amazon-EC2-Linux-Instance?)

Problembehandlung bei gedrosselter Leistung des EBS-Root-Volumes

Wenn das EBS-Volume seine Grenzwerte für Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) oder den Durchsatz überschreitet, drosselt Amazon EC2 das Volume. Infolgedessen schlagen die Statusprüfungen der Instance fehl und sie reagiert nicht mehr.

Überwache und analysiere CloudWatch-Metriken für Amazon EBS, um das erwartete Volume, IOPS oder den Durchsatz zu verstehen.

Hinweis: Um ein gedrosseltes Volume zu identifizieren, suche nach IOPS- oder Durchsatzmetriken, die im Laufe der Zeit gleich bleiben. Weitere Informationen findest du unter E/A-Eigenschaften mit CloudWatch überwachen.

Um das Problem vorübergehend zu beheben, starte die Instance neu oder halte sie an und starte sie, um die Prozesse zu beenden, die IOPS und den Durchsatz verwenden. Führe für eine langfristige Lösung ein Upgrade auf einen EBS-Volume-Typ und eine EBS-Volume-Größe durch, die sich besser für deine Workload eignen.