Wie behebe ich Absturzursachen in meinem SSM Agent-Fehlerprotokoll?

Kurzbeschreibung

Bei Run Command, Association, Automation oder Sessions Manager, einer Funktion von Systems Manager, schlagen Systems-Manager-Befehle möglicherweise auf Ziel-Instances fehl. Diese Fehler verursachen einen Fehler ähnlich dem folgenden:

„document process failed unexpectedly: document worker timed out; check [ssm-document-worker]/[ssm-session-worker] log for crash reason.“

Dieser Fehler tritt aus den folgenden Gründen auf:

• Ungenügende Ressourcen
• Unzureichender Speicher (OOM)
• Nicht genug Speicherplatz auf der Festplatte
• Zu viele geöffnete Dateien

Weitere Informationen zur Problembehandlung findest du in den SSM-Agent-Protokollen auf der Instance.

Hinweis: Aktualisiere SSM Agent auf die neueste Version, um eine bessere Leistung, Sicherheit und Zugriff auf die neuesten Funktionen zu erzielen. Abonniere außerdem amazon-ssm-agent/RELEASE NOTES auf der GitHub-Website, um Benachrichtigungen über SSM-Agent-Aktualisierungen zu erhalten.

Lösung

Ungenügende Ressourcen

Wenn in einer Sitzung bei einer Ziel-Instance Ressourcenbeschränkungen auftreten, wie z. B. ein Überschreiten des Arbeitsspeichers oder des Festplattenspeichers, kann die Sitzung abstürzen und Systemfehlfunktionen verursachen. Stelle sicher, dass die Instances über genügend Ressourcen verfügen, um die Workload zu verwalten, die auf den Ziel-Instances ausgeführt wird.

OOM

OOM-Fehler treten auf, wenn laufende Prozesse den gesamten verfügbaren Speicher nutzen und ein Programm oder Betriebssystem keinen Speicherplatz zuweisen kann. Das betroffene System kann keine zusätzlichen Programme laden und die zugehörigen Prozesse funktionieren nicht mehr richtig. Das Betriebssystem deaktiviert dann Prozesse, die es als niedrig priorisiert einstuft.

Um zu überprüfen, ob unzureichender Arbeitsspeicher diesen Fehler verursacht, siehe Problembehandlung bei einer nicht erreichbaren Instance. Informationen zu Linux-OOM-Problemen findest du unter Unzureichender Arbeitsspeicher: Prozess beenden.

Nicht genug Speicherplatz auf der Festplatte

Dieser Fehler tritt auf einem Linux-System auf, wenn du versuchst, Daten zu schreiben oder Dateien zu speichern, aber nicht genügend Speicherplatz vorhanden ist. Gehe wie folgt vor, um diesen Fehler zu beheben:

• Überprüfe die Dateien, die viel Speicherplatz auf der Festplatte oder Partition belegen.
• Gib zusätzlichen Speicherplatz auf der Partition frei.
• Prüfe, ob unter den Arbeitsverzeichnissen, einschließlich der Systems-Manager-Orchestrierungsordner, die sich in /var/lib/amazon/ssm befinden, ausreichend Speicherplatz vorhanden ist.
• Vergrößere den Speicherplatz. Weitere Informationen findest du unter Wie vergrößere ich mein EBS-Volume, wenn ich eine Fehlermeldung erhalte, dass auf meinem Dateisystem kein Speicherplatz mehr verfügbar ist?

Zu viele geöffnete Dateien

Wenn Linux-Instances die Verarbeitung von Systems Manager Run Command aufgrund eines Absturzes von Document Worker beenden, erhältst du möglicherweise die Fehlermeldung too many open files. Wenn zu viele Dateien geöffnet sind, kann SSM Agent die Befehlsprozessoren nicht starten und meldet diesen Fehler in den Agent-Protokollen. Dieser Fehler tritt in den folgenden Szenarien auf:

• Der SSM-Agent-Prozess hat die maximale Anzahl offener Dateien für den Root-Benutzer erreicht.
• Die Gesamtzahl der geöffneten Dateien im gesamten System hat die systemweite Grenze der maximal geöffneten Dateien erreicht.
• Das System hat die Grenze für die Benachrichtigung des Subsystems im Kernel erreicht.

Führe die folgenden Schritte aus, um diesen Fehler zu beheben:

1.     Identifiziere die PID des SSM-Agent-Prozesses:

$ sudo ps -C amazon-ssm-agent -o pid=

2.    Identifiziere die Grenzwerte der PID. Die erste Zahl ist das weiche Limit und die zweite Zahl ist das harte Limit.

$ sudo cat /proc/_**PID**_/limits |grep "Max open files"

3.    Identifiziere die Gesamtzahl der geöffneten Dateien aus dem Systems-Manager-Prozess:

$ sudo lsof -p _**PID**_ |wc -l

4.    Vergleiche die Ergebnisse zwischen den Schritten 2 und 3. Wenn die Gesamtzahl der geöffneten Dateien nahe am festen Grenzwert liegt, verhindert dies möglicherweise, dass neue Dateien geöffnet werden. Gehe wie folgt vor, um dieses Problem zu beheben:

• Starte SSM Agent neu.
• Lege in den Startdateien von SSM Agent einen höheren Wert für das harte Limit fest:

Hinweis: Ersetze alle Beispiel-Zeichenfolgen durch deine Werte.

Upstart: Amazon Linux 1, Ubuntu 14.04 und Ubuntu 16.04 mit dem DEB-Paket

echo "limit nofile example-hard-limit" >> /etc/init/amazon-ssm-agent.override

Systemd: Amazon Linux 2, RHEL 7.x und RHEL 8.x 

$ sudo systemctl edit amazon-ssm-agent  [Service]  LimitNOFILE=example-hard-limit

Systemd: Ubuntu 22.04 LTS, 20.10 STR & 20.04, 18.04 (unter Verwendung von Snap)

$ sudo systemctl edit snap.amazon-ssm-agent.amazon-ssm-agent  [Service]  LimitNOFILE=example-hard-limit

5.    Starte den SSM-Agent-Service neu.

Hinweis: Wenn du das harte Limit aktualisierst, überprüfe die Anforderungen der Anwendung, einschließlich der Anzahl gleichzeitiger Benutzer, Netzwerkverbindungen und Dateioperationen. Um Missbrauch und Erschöpfung der Ressourcen zu verhindern, sind die Standardgrenzwerte niedrig festgelegt. Stelle sicher, dass du das neue harte Limit einem Stresstest unterziehst. Überwache das harte Limit und passe es bei Bedarf an.

Überprüfe die Worker-Protokolle

Gehe wie folgt vor, um die Worker-Protokolle zu überprüfen:

1.    Sieh dir die SSM-Agent-Protokolle an. SSM Agent verwaltet Informationen in den folgenden Dateien:

Hinweis: Um die verfügbaren Protokolldateien und ihren Zweck zu verstehen, empfiehlt es sich, die offizielle Dokumentation für das von dir verwendete Betriebssystem zu lesen.

• Linux – /var/log/amazon/ssm/amazon-ssm-agent.log
• Linux – /var/log/amazon/ssm/errors.log
• Windows – %PROGRAMDATA%\Amazon\SSM\Logs\amazon-ssm-agent.log
• Windows – %PROGRAMDATA%\Amazon\SSM\Logs\errors.log

2.    Überprüfe die Protokolle auf Betriebssystemebene auf Software- oder Kernel-Probleme:

• Windows – C:\Windows\System32\winevt\Logs
• Ubuntu/ Debian – /var/log/syslog
• Amazon Linux/ CentOS/ RHEL – /var/log/messages
• Suse – /var/log/messages

3.    Aktualisiere die seelog.xml-Datei, um die Debug-Protokollierung des SSM Agent zu ermöglichen.

Hinweis: Die Debug-Protokollierung des SSM Agent generiert große Mengen an Protokolldaten, die sich auf den Systemspeicher auswirken können. Nach Abschluss der Problembehandlung empfiehlt es sich, die Debug-Protokollierung zu deaktivieren.

Ähnliche Informationen

Fehlerbehebung bei SSM-Agent