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, eine Funktion von AWS Systems Manager, meldet detaillierte Statusinformationen über die verschiedenen Zustände, 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 Symbol Refresh (Aktualisieren) auf der Registerkarte Commands (Befehle) in der Run Command-Konsolenschnittstelle.
-
Rufen Sie list-commands auf oder list-command-invocationsverwenden Sie die AWS Command Line Interface ()AWS CLI. Oder rufen Sie Get- SSMCommand oder Get- SSMCommandInvocation using auf. AWS Tools for Windows PowerShell
-
Konfigurieren Sie Amazon so EventBridge , dass es auf Status- oder Statusänderungen reagiert.
-
Konfigurieren Sie Amazon Simple Notification Service (AmazonSNS) so, dass Benachrichtigungen für alle Statusänderungen oder bestimmte Status wie
Failed
oderTimedOut
gesendet werden.
Run Command-Status
Run Command berichtet Statusdetails für drei Bereiche: Plugins, Aufrufe und eine allgemeinen Compliance-Befehl. Ein Plugin ist ein Block zur Codeausführung, der im Dokument Ihres Befehls definiert ist. SSM Weitere Informationen zu den Plug-ins finden Sie unter Referenz für Befehlsdokument-Plug-ins.
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 Plug-ins 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 Plug-ins 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 einer Vielzahl von Bedingungen zurückgegeben. Dieser Status bedeutet nicht, dass der Befehl auf dem Knoten verarbeitet wurde. Beispielsweise kann der Befehl SSM Agent auf dem verwalteten Knoten empfangen werden und den Exit-Code Null zurückgeben, wenn Sie die Ausführung des Befehls PowerShell ExecutionPolicy verhindern. 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 Plug-in bedeutet dies, dass der Ergebniscode nicht null war. Für einen Befehlsaufruf bedeutet dies, dass der Ergebniscode für ein oder mehrere Plug-ins 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 Benutzer oder die Rolle AWS Identity and Access Management (IAM), der den Befehl initiiert, 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 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 mithilfe des AWS-RunShellScript
SSM Dokuments ausführen, beträgt der Standardwert von "timeoutSeconds„: „{{ executionTimeout }}“ 3600 Sekunden, wie im folgenden Dokumentbeispiel dargestellt:
"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 für alle SSM Dokumente ist es erforderlich, dass Sie ein Ausführungs-Timeout angeben. Das Feld Ausführungs-Timeout wird nur angezeigt, wenn im Dokument ein entsprechender Eingabeparameter definiert wurde. SSM 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 Wert für das Ausführungstimeout angeben, erzwingt Systems Manager das hartcodierte Standard-Ausführungstimeout.
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 deliveryTimeout
gekennzeichnet.
SSM AgentKombiniert alle Parameter und den Inhalt des zu berechnenden Dokuments, um den Timeout-Status für ein Ziel zu ermitteln. SSM executionTimeout
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 AgentDie Prozesse sind je nach SSM Dokumenttyp und Dokumentversion executionTimeout
unterschiedlich.