Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Grundlegendes zu Befehlsstatus
Run Command, ein Tool in AWS Systems Manager, meldet detaillierte Statusinformationen zu den verschiedenen Zuständen, die ein Befehl während der Verarbeitung erlebt, und für jeden verwalteten Knoten, der den Befehl verarbeitet hat. Sie können Befehlsstatus mithilfe der folgenden Methoden überwachen:
-
Wählen Sie das Aktualisierungssymbol auf der Registerkarte Befehle im Run Command Konsolenoberfläche.
-
Rufen Sie list-commands auf oder list-command-invocationsverwenden Sie die AWS Command Line Interface ()AWS CLI. Oder rufen Sie Get- SSMCommand oder Get- SSMCommand Invocation auf mit. AWS Tools for Windows PowerShell
-
Konfigurieren Sie Amazon so EventBridge , dass es auf Status- oder Statusänderungen reagiert.
-
Konfigurieren Sie Amazon Simple Notification Service (Amazon SNS), um Benachrichtigungen für alle Statusänderungen oder bestimmte Status wie
Failed
oderTimedOut
zu senden.
Run Command Status
Run Command meldet Statusdetails für drei Bereiche: Plugins, Aufrufe und einen allgemeinen Befehlsstatus. Ein Plugin ist ein Code-Ausführungsblock, der im SSM-Dokument des Befehls definiert ist. Weitere Informationen zu den Plugins finden Sie unter Referenz für Befehlsdokument-Plugins.
Wenn Sie einen Befehl an mehrere verwaltete Knoten gleichzeitig senden, ist jede Kopie des Befehls, die jeden Knoten anvisiert, ein Befehlsaufruf. Wenn Sie z. B. das AWS-RunShellScript
-Dokument verwenden und einen ifconfig
-Befehl an 20 Linux-Instances senden, hat dieser Befehl 20 Aufrufe. Jeder Befehlsaufruf berichtet einzeln einen Status. Die Plugins für einen bestimmten Befehlsaufruf berichten ebenfalls einzeln einen Berichtstatus.
Zu guter Letzt Run Command beinhaltet einen aggregierten Befehlsstatus für alle Plugins und Aufrufe. Der aggregierte Befehlsstatus kann von dem Status, der von Plugins oder Aufrufen gemeldet wird, wie in den folgenden Tabellen gezeigt, abweichen.
Anmerkung
Wenn Sie Befehle mit den Parametern max-concurrency
oder max-errors
für eine großen Anzahl von verwalteten Knoten ausführen, spiegelt der Befehlsstatus die durch diese Parameter auferlegten Grenzen wider, wie in den folgenden Tabellen beschrieben. Weitere Informationen zu diesen Parametern finden Sie unter Ausführen von Befehlen in großem Maßstab.
Status | Details |
---|---|
Ausstehend | Der Befehl wurde noch nicht an den verwalteten Knoten gesendet oder wurde nicht von empfangen SSM Agent. Wenn der Befehl nicht vom Agenten empfangen wird, bevor die Zeitdauer verstrichen ist, die der Summe der Parameter Timeout (Sekunden) und des Parameters für das Ausführungstimeout entspricht, ändert sich der Status in. Delivery Timed Out |
InProgress | Systems Manager versucht, den Befehl an den verwalteten Knoten zu senden, oder der Befehl wurde empfangen von SSM Agent und hat begonnen, auf der Instanz zu laufen. Je nach Ergebnis aller Befehls-Plugins ändert sich der Status in Success , Failed , Delivery
Timed Out , oder Execution Timed Out . Ausnahme: Wenn der Agent nicht ausgeführt oder auf dem Knoten nicht verfügbar ist, bleibt der Befehlsstatus bei In
Progress , bis der Agent wieder verfügbar ist oder bis das Ausführungs-Timeout-Limit erreicht ist. Der Status wechselt dann in einen Terminal-Status. |
Verzögert | Das System versuchte, den Befehl an den verwalteten Knoten zu senden, war jedoch nicht erfolgreich. Das System startet einen erneuten Versuch. |
Herzlichen Glückwunsch | Dieser Status wird unter verschiedenen Bedingungen zurückgegeben. Dieser Status bedeutet nicht, dass der Befehl auf dem Knoten verarbeitet wurde. Der Befehl kann beispielsweise empfangen werden von SSM Agent auf dem verwalteten Knoten und geben den Exit-Code Null zurück, weil Sie die Ausführung des Befehls PowerShell ExecutionPolicy verhindert haben. Diese ist ein Terminalstatus. Bedingungen, die dazu führen, dass ein Befehl einen Success Status zurückgibt, sind:
AnmerkungDieselben Bedingungen gelten für die Ausrichtung auf Ressourcengruppen. Um Fehler zu beheben oder weitere Informationen über die Befehlsausführung zu erhalten, senden Sie einen Befehl, der Fehler oder Ausnahmen handhabt, indem er entsprechende Beendigungscodes (Ausgangscodes für fehlgeschlagenen Befehl (nicht null)) zurückgibt. |
DeliveryTimedOut | Der Befehl wurde nicht an den verwalteten Knoten übermittelt, bevor die gesamte Zeitbeschränkung abgelaufen ist. Gesamtausfälle werden nicht auf die übergeordnete Befehlsbegrenzung angerechnet max-errors , aber sie tragen dazu bei, ob der übergeordnete Befehlsstatus Success , Incomplete oder Delivery Timed Out ist. Diese ist ein Terminalstatus. |
ExecutionTimedOut | Die Befehlsautomatisierung begann auf dem verwalteten Knoten, aber der Befehl wurde vor Ablauf des Ausführungs-Timeouts nicht abgeschlossen. Ausführungs-Timeouts zählen als Fehler, wodurch eine Antwort ungleich Null gesendet wird, und Systems Manager beendet den Versuch, die Befehlsautomatisierung auszuführen, und meldet einen Fehlerstatus. |
Fehlgeschlagen | Der Befehl war auf dem verwalteten Knoten nicht erfolgreich. Für ein Plugin bedeutet dies, dass der Ergebniscode nicht null war. Für einen Befehlsaufruf bedeutet dies, dass der Ergebniscode für ein oder mehrere Plugins nicht null war. Zeitüberschreitungen beim Aufrufen werden auf das max-errors Limit des übergeordneten Befehls angerechnet. Diese ist ein Terminalstatus. |
Abgebrochen | Der Befehl wurde beendet, bevor er abgeschlossen wurde. Diese ist ein Terminalstatus. |
Unzustellbar | Der Befehl kann nicht an den verwalteten Knoten übermittelt werden. Der Knoten existiert möglicherweise nicht oder antwortet nicht. Unzustellbare Aufrufe werden nicht auf die übergeordnete Befehlsbegrenzung angerechnet max-errors , aber sie tragen dazu bei, ob der übergeordnete Befehlsstatus Success oder Incomplete ist. Wenn beispielsweise alle Aufrufe in einem Befehl den Status Undeliverable haben, lautet der zurückgegebene Befehlsstatus Failed . Wenn ein Befehl jedoch fünf Aufrufe hat, von denen vier den Status Undeliverable zurückgeben und einer den Status Success zurückgibt, lautet der Status des übergeordneten Befehls Success . Diese ist ein Terminalstatus. |
Beendet | Der übergeordnete Befehl hat sein Limit max-errors überschritten, und nachfolgende Befehlsaufrufe wurden vom System abgebrochen. Diese ist ein Terminalstatus. |
InvalidPlatform | Der Befehl wurde an einen verwalteten Knoten gesendet, der nicht den erforderlichen Plattformen entspricht, wie sie im ausgewählten Dokument festgelegt wurden. Invalid
Platform wird nicht auf die maximale Fehlerbegrenzung des übergeordneten Befehls angerechnet, aber es trägt dazu bei, ob der übergeordnete Befehlsstatus Success oder Failed lautet. Wenn beispielsweise alle Aufrufe in einem Befehl den Status Invalid Platform haben, lautet der zurückgegebene Befehlsstatus Failed . Wenn ein Befehl jedoch fünf Aufrufe hat, von denen vier den Status Invalid Platform zurückgeben und einer den Status Success zurückgibt, lautet der Status des übergeordneten Befehls Success . Diese ist ein Terminalstatus. |
AccessDenied | Der AWS Identity and Access Management (IAM-) Benutzer oder die Rolle, die den Befehl initiiert hat, hat keinen Zugriff auf den verwalteten Zielknoten. Access Denied wird nicht auf das max-errors Limit des übergeordneten Befehls angerechnet, trägt aber dazu bei, ob der Status des übergeordneten Befehls oder lautetSuccess . Failed Wenn beispielsweise alle Aufrufe in einem Befehl den Status Access Denied haben, lautet der zurückgegebene Befehlsstatus Failed . Wenn ein Befehl jedoch fünf Aufrufe hat, von denen vier den Status Access Denied zurückgeben und einer den Status Success zurückgibt, lautet der Status des übergeordneten Befehls Success . Diese ist ein Terminalstatus. |
Status | Details |
---|---|
Ausstehend | Der Befehl wurde noch von keinem Agenten auf einem verwalteten Knoten empfangen. |
InProgress | Der Befehl wurde an mindestens einen verwalteten Knoten gesendet, hat aber keinen endgültigen Status auf allen Knoten erreicht. |
Verzögert | Das System versuchte, den Befehl an den Knoten zu senden, war jedoch nicht erfolgreich. Das System startet einen erneuten Versuch. |
Herzlichen Glückwunsch | Der Befehl wurde empfangen von SSM Agent auf allen angegebenen oder als Ziel verwalteten Knoten und gab den Exit-Code Null zurück. Alle Befehlsaufrufe haben einen endgültigen Status erreicht, und der Wert von max-errors wurde nicht erreicht. Dieser Status bedeutet nicht, dass der Befehl auf allen angegebenen oder anvisierten verwalteten Knoten erfolgreich verarbeitet wurde. Diese ist ein Terminalstatus. AnmerkungUm Fehler zu beheben oder weitere Informationen über die Befehlsausführung zu erhalten, senden Sie einen Befehl, der Fehler oder Ausnahmen handhabt, indem er entsprechende Beendigungscodes (Ausgangscodes für fehlgeschlagenen Befehl (nicht null)) zurückgibt. |
DeliveryTimedOut | Der Befehl wurde nicht an den verwalteten Knoten übermittelt, bevor die gesamte Zeitbeschränkung abgelaufen ist. Der Wert max-errors oder weitere Befehlsaufrufe zeigen den Status Delivery Timed
Out . Diese ist ein Terminalstatus. |
Fehlgeschlagen |
Der Befehl war auf dem verwalteten Knoten nicht erfolgreich. Der Wert |
Unvollständig | Der Befehl wurde auf allen verwalteten Knoten versucht und einer oder mehrere der Aufrufe haben nicht den Wert Success . Jedoch sind nicht genügend Aufrufe fehlgeschlagen für den Status Failed . Diese ist ein Terminalstatus. |
Abgebrochen | Der Befehl wurde beendet, bevor er abgeschlossen wurde. Diese ist ein Terminalstatus. |
RateExceeded | Die Anzahl der verwalteten Knoten, die durch den Befehl anvisiert wurden, überschritt das Kontingent Ihres Kontos für ausstehende Aufrufe. Das System hat den Befehl vor der Ausführung auf einem Knoten abgebrochen. Diese ist ein Terminalstatus. |
AccessDenied | Der Benutzer oder die Rolle, der oder die den Befehl initiiert, hat keinen Zugriff auf die Zielressourcengruppe. AccessDenied zählt nicht zum max-errors -Limit des übergeordneten Befehls, trägt aber dazu bei, ob der Status des übergeordneten Befehls Success oder Failed ist. (Wenn beispielsweise alle Aufrufe in einem Befehl den Status AccessDenied haben, dann lautet der zurückgegebene Befehlsstatus Failed . Wenn ein Befehl jedoch 5 Aufrufe hat, von denen 4 den Status AccessDenied anzeigen und 1 davon den Status Success anzeigt, dann lautet der Status des übergeordneten Befehls Success .) Diese ist ein Terminalstatus. |
Keine Instances im Tag | Der Tag-Schlüsselpaar-Wert oder die Ressourcengruppe, auf die der Befehl ausgerichtet ist, stimmt mit keinem verwalteten Knoten überein. Diese ist ein Terminalstatus. |
Informationen zu Timeout-Werten von Befehlen
Systems Manager erzwingt die folgenden Timeout-Werte bei der Ausführung von Befehlen.
Gesamt-Timeout
Geben Sie in der Systems-Manager-Konsole den Zeitbeschränkungs-Wert im Feld Timeout (seconds) (Zeitbeschränkung (Sekunden)) ein. Nachdem ein Befehl gesendet wurde, Run Command prüft, ob der Befehl abgelaufen ist oder nicht. Wenn ein Befehl das Ablauflimit des Befehls (Gesamtzeitlimit) erreicht, ändert er den Status in DeliveryTimedOut
für alle Aufrufe, die den Status InProgress
, Pending
oder Delayed
haben.

Technisch gesehen ist die gesamte Zeitbeschränkung (Timeout (Sekunden)) eine Kombination aus zwei Timeout-Werten, wie hier gezeigt:
Total timeout = "Timeout(seconds)" from the console + "timeoutSeconds": "{{
executionTimeout }}" from your SSM document
Beispielsweise beträgt der Standardwert von Timeout (seconds) (Timeout (Sekunden)) 600 Sekunden in der Systems Manager-Konsole. Wenn Sie einen Befehl mit dem AWS-RunShellScript
-SSM-Dokument ausführen, beträgt der Standardwert von „timeoutSeconds“: „{{executionTimeout}}“ 3600 Sekunden, wie im folgenden Dokumentbeispiel gezeigt:
"executionTimeout": { "type": "String", "default": "3600", "runtimeConfig": { "aws:runShellScript": { "properties": [ { "timeoutSeconds": "{{ executionTimeout }}"
Das bedeutet, dass der Befehl 4 200 Sekunden (70 Minuten) lang ausgeführt wird, bevor das System den Befehlsstatus auf DeliveryTimedOut
setzt.
Execution Timeout
In der Systems Manager-Konsole geben Sie den Wert für die Ausführungszeitüberschreitung im Feld Execution Timeout an, sofern verfügbar. Nicht alle SSM-Dokumente erfordern die Angabe eines Ausführungs-Timeout. Das Feld Execution Timeout (Ausführungszeitlimit) wird nur angezeigt, wenn ein entsprechender Eingabeparameter im SSM-Dokument definiert wurde. Falls angegeben, muss der Befehl innerhalb dieser Zeitspanne abgeschlossen werden.
Anmerkung
Run Command stützt sich auf SSM Agent Dokumentieren Sie die Antwort des Terminals, um festzustellen, ob der Befehl an den Agenten übermittelt wurde oder nicht. SSM Agent muss ein ExecutionTimedOut
Signal senden, damit ein Aufruf oder Befehl als ExecutionTimedOut
markiert werden kann.

Standard-Ausführungs-Timeout
Wenn ein SSM-Dokument nicht erfordert, dass Sie explizit einen Ausführungs-Timeout-Wert angeben, erzwingt Systems Manager den fest programmierten Standard-Ausführungs-Timeout.
Wie Systems Manager Timeouts meldet
Wenn Systems Manager eine execution timeout
Antwort erhält von SSM Agent auf einem Ziel markiert Systems Manager den Befehlsaufruf alsexecutionTimeout
.
Wenn Run Command erhält keine Antwort auf das Dokumententerminal von SSM Agent, der Befehlsaufruf ist als deliveryTimeout
markiert.
Um den Timeout-Status auf einem Ziel zu ermitteln, SSM Agent kombiniert alle Parameter und den Inhalt des SSM-Dokuments, für das berechnet werden soll. executionTimeout
Wann SSM Agent stellt fest, dass bei einem Befehl das Timeout überschritten wurde, und wird executionTimeout
an den Dienst gesendet.
Der Standardwert für Timeout (seconds) (Timeout (Sekunden)) beträgt 3600 Sekunden. Der Standardwert für Execution Timeout beträgt ebenfalls 3600 Sekunden. Daher beträgt die gesamte Standard-Timeout für einen Befehl 7200 Sekunden.
Anmerkung
SSM Agent verarbeitet je nach Art des SSM-Dokuments und Version des Dokuments executionTimeout
unterschiedlich.