• Das AWS Systems Manager CloudWatch Dashboard wird nach dem 30. April 2026 nicht mehr verfügbar sein. Kunden können weiterhin die CloudWatch Amazon-Konsole verwenden, um ihre CloudWatch Amazon-Dashboards anzusehen, zu erstellen und zu verwalten, so wie sie es heute tun. Weitere Informationen finden Sie in der [Amazon CloudWatch Dashboard-Dokumentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
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 Symbol **Refresh** (Aktualisieren) auf der Registerkarte **Commands** (Befehle) in der Run Command-Konsolenschnittstelle.
+ Rufen Sie [list-commands](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-commands.html) auf oder [list-command-invocations](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-command-invocations.html)verwenden Sie die AWS Command Line Interface ()AWS CLI. Oder rufen Sie [Get- SSMCommand](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-SSMCommand.html) oder [Get- SSMCommand Invocation](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-SSMCommandInvocation.html) 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` oder `TimedOut` zu 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](documents-command-ssm-plugin-reference.md).
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](send-commands-multiple.md).
**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 verschiedenen Bedingungen zurückgegeben. Dieser Status bedeutet nicht, dass der Befehl auf dem Knoten verarbeitet wurde. Der Befehl kann beispielsweise 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: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/monitor-commands.html) 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 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 Deniedwird 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. |
**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. 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.
![\[Das Feld Timeout (seconds) in der Systems Manager-Konsole\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/run-command-delivery-time-out-time-out-seconds.png)
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“: „\$1\$1executionTimeout\$1\$1“** 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.
![\[Das Feld Execution Timeout (Ausführungs-Timeout) in der Systems Manager-Konsole\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/run-command-execution-timeout-console.png)
**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 `deliveryTimeout`gekennzeichnet.
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.