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 oder TimedOut 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.

Detaillierter Status für Befehls-Plugins und Aufrufe
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: Bei der Ausrichtung auf eine einzelne Instanz wurde der Befehl SSM Agent auf dem verwalteten Knoten empfangen und es wurde der Exit-Code Null zurückgegeben. Beim Targeting auf mehrere Instanzen hat die Anzahl der fehlgeschlagenen Aufrufe den im Befehl angegebenen Fehlerschwellenwert nicht überschritten. Beim Targeting auf mehrere Instanzen war mindestens ein Aufruf erfolgreich, während bei anderen das Timeout abgelaufen ist. Der angegebene Fehlerschwellenwert gilt weiterhin. Beim Targeting auf ein Tag werden keine Instanzen gefunden, die dem Tag zugeordnet sind. Beim Targeting auf ein Tag hat die Anzahl der fehlgeschlagenen Aufrufe den im Befehl angegebenen Fehlerschwellenwert nicht überschritten. Beim Targeting auf ein Tag war mindestens ein Aufruf erfolgreich, während bei anderen das Timeout abgelaufen ist. Der angegebene Fehlerschwellenwert gilt weiterhin. Sie haben Anwendungen oder Richtlinien, die auf Betriebssystemebene durchgesetzt werden und die Ausführung eines Befehls verhindern oder überschreiben, was dazu führt, dass der Exit-Code Null zurückgegeben wird. Anmerkung Dieselben 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 Deniedwird 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.

Detaillierter Status für einen Befehl
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. Anmerkung 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. 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 max-errors oder weitere Befehlsaufrufe zeigen den Status Failed. Diese ist ein Terminalstatus.
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 deliveryTimeoutgekennzeichnet.

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.