Grundlegendes zu Befehlsstatus
Run Command, ein Tool in AWS Systems Manager, sendet detaillierte Informationen zu den verschiedenen Zuständen, die ein Befehl während der Verarbeitung durchläuft, sowie für jeden verwalteten Knoten, der den Befehl verarbeitet. Sie können Befehlsstatus mithilfe der folgenden Methoden überwachen:
-
Wählen Sie das Symbol Refresh (Aktualisieren) auf der Registerkarte Commands (Befehle) in der Run Command-Konsolenschnittstelle.
-
Rufen Sie list-commands oder list-command-invocations mittels der AWS Command Line Interface (AWS CLI) auf. Sie können auch Get-SSMCommand oder Get-SSMCommandInvocation mittels AWS Tools for Windows PowerShell verwenden.
-
Konfigurieren Sie Amazon EventBridge, um auf Änderungen des Status oder Statusänderungen zu reagieren.
-
Konfigurieren Sie Amazon Simple Notification Service (Amazon SNS), um Benachrichtigungen für alle Statusänderungen oder bestimmte Status wie
FailedoderTimedOutzu senden.
Run Command-Status
Run Command berichtet Statusdetails für drei Bereiche: Plugins, Aufrufe und eine allgemeinen Compliance-Befehl. 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.
Schließlich umfasst Run Command einen zusammenfassenden 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 vom SSM Agent empfangen. Wird der Befehl nicht vor Ablauf der Zeitspanne, die der Summe aus dem Parameter Timeout (seconds) und dem Parameter Execution timeout entspricht, vom Agenten empfangen, ändert sich der Status in Delivery Timed Out. |
| InProgress | Systems Manager versucht, den Befehl an den verwalteten Knoten zu senden, oder der Befehl wurde vom SSM Agent empfangen und wird auf der Instance ausgeführt. 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 von SSM Agent auf dem verwalteten Knoten empfangen werden und den Beendigungscode Null zurückgeben, weil Ihre PowerShell die Ausführung des Befehls ExecutionPolicy verhindert. 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 IAM-Rolle, der/die den Befehl initiiert, hat keinen Zugriff auf den anvisierten verwalteten Knoten. Access Denied zählt nicht in Bezug auf das max-errors-Limit des übergeordneten Befehls, es trägt aber dazu bei, ob der übergeordnete Befehlsstatus Success oder Failed lautet. 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 vom SSM Agent auf allen angegebenen oder anvisierten verwalteten Knoten empfangen und ein Ausgangscode von null wurde zurückgegeben. 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, prüft Run Command, 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 die SSM Agent-Dokument-Terminalantwort, um zu bestimmen, 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 wird.
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
Empfängt Systems Manager eine execution timeout-Antwort von SSM Agent auf einem Ziel, dann markiert Systems Manager den Befehlsaufruf als executionTimeout.
Erhält Run Command keine Dokumentterminalantwort von SSM Agent, wird der Befehlsaufruf als deliveryTimeoutgekennzeichnet.
Um den Timeout-Status für ein Ziel zu bestimmen, kombiniert SSM Agent alle Parameter und den Inhalt des SSM-Dokuments, um executionTimeout zu berechnen. Wenn SSM Agent feststellt, dass ein Befehl einen Timeout hat, sendet es executionTimeout an den Service.
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 executionTimeout unterschiedlich, je nach Art des SSM-Dokuments und der Dokumentversion.
