Comprendre les états des commandes - AWS Systems Manager

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comprendre les états des commandes

Run Command, une fonctionnalité de AWS Systems Manager, fournit des informations d'état détaillées sur les différents états rencontrés par une commande pendant le traitement et pour chaque nœud géré qui a traité la commande. Vous pouvez surveiller les statuts de commande à l'aide des méthodes suivantes :

  • Cliquez sur l'icône Refresh (Actualiser) dans l'onglet Commands (Commandes) de l'interface de la console Run Command.

  • Appelez les commandes de liste ou list-command-invocationsutilisez le AWS Command Line Interface ()AWS CLI. Ou appelez Get- SSMCommand or Get- SSMCommandInvocation using AWS Tools for Windows PowerShell.

  • Configurez Amazon EventBridge pour répondre aux changements d'état ou de statut.

  • Configurez Amazon Simple Notification Service (AmazonSNS) pour envoyer des notifications pour tous les changements de statut ou pour des statuts spécifiques tels que Failed ouTimedOut.

État Run Command

La fonctionnalité Run Command génère des rapports avec des détails de statut pour trois domaines : plug-ins, appels et statut de commande général. Un plugin est un bloc d'exécution de code défini dans le document de SSM votre commande. Pour de plus amples informations sur les plug-ins, consultez Référence de plug-in de document Command.

Lorsque vous envoyez une commande à plusieurs nœuds gérés en même temps, chaque copie de la commande qui cible chaque nœud correspond à une invocation de commande. Par exemple, si vous utilisez le document AWS-RunShellScript et que vous envoyez une commande ifconfig à 20 instances Linux, cette commande aura 20 appels. Chaque invocation de commande signale le statut individuellement. Les plug-ins d'une invocation de commande donné communiquent aussi le statut individuellement.

Enfin, la fonctionnalité Run Command inclut un statut de commande regroupé pour tous les plug-ins et les appels. Le statut de commande regroupé peut être différent du statut signalé par plug-ins ou appels, comme indiqué dans les tableaux suivants.

Note

Si vous exécutez des commandes sur un grand nombre de nœuds gérés à l'aide des paramètres max-concurrency ou max-errors, le statut de commande reflète les limites imposées par ces paramètres, comme décrit dans les tableaux suivants. Pour obtenir plus d'informations sur ces paramètres, consultez Exécuter des commandes à grande échelle.

Statut détaillé pour des plug-ins et des appels de commande
Statut Détails
En attente La commande n'a pas encore été envoyée au nœud géré ou n'a pas été reçue par l'SSM Agent. Si la commande n'est pas reçue par l'agent avant le délai prévu, qui est égal à la somme du paramètre Timeout (seconds) (Délai d'expiration (secondes)) et le paramètre Execution timeout (Délai d'exécution), le statut passe à Delivery Timed Out.
InProgress Systems Manager tente d'envoyer la commande au nœud géré, ou la commande a été reçue par l'SSM Agent et a commencé à s'exécuter sur l'instance. Selon le résultat de tous les plug-ins de commande, le statut passe à Success, Failed, Delivery Timed Out ou Execution Timed Out. Exception : si l'agent n'est pas en cours d'exécution ou n'est pas disponible sur le nœud, le statut de la commande reste sur In Progress jusqu'à ce que l'agent soit à nouveau disponible ou que la limite du délai d'exécution soit atteinte. Le statut est ensuite remplacé par un état de mise hors service.
Delayed (Retardé) Le système tente d'envoyer la commande au nœud géré, mais n'a pas réussi. Le système réessaie.
Réussite Ce statut est renvoyé sous diverses conditions. Ce statut ne signifie pas que la commande a été effectuée sur le nœud. Par exemple, la commande peut être reçue par SSM Agent le nœud géré et renvoyer un code de sortie égal à zéro si vous PowerShell ExecutionPolicy empêchez l'exécution de la commande. Il s’agit d’un statut de terminal. Les conditions qui entraînent le renvoi d'un Success statut par une commande sont les suivantes :
  • Lors du ciblage d'une instance unique, la commande était reçue par SSM Agent le nœud géré et renvoyait un code de sortie égal à zéro.

  • Lorsque vous ciblez plusieurs instances, le nombre d'appels ayant échoué n'a pas dépassé le seuil d'erreur spécifié dans la commande.

  • Lorsque vous ciblez plusieurs instances, au moins une invocation a réussi tandis que les autres ont expiré. Le seuil d'erreur spécifié s'applique toujours.

  • Lorsque vous ciblez une balise, aucune instance associée à la balise n'est trouvée.

  • Lorsque vous ciblez une balise, le nombre d'appels ayant échoué n'a pas dépassé le seuil d'erreur spécifié dans la commande.

  • Lorsque vous ciblez un tag, au moins un appel a réussi alors que les autres ont expiré. Le seuil d'erreur spécifié s'applique toujours.

  • Certaines applications ou politiques appliquées au niveau du système d'exploitation empêchent ou annulent l'exécution d'une commande, ce qui entraîne le renvoi d'un code de sortie égal à zéro.

Note

Les mêmes conditions s'appliquent lorsque vous ciblez des groupes de ressources. Pour résoudre les erreurs ou obtenir plus d'informations sur l'exécution des commandes, envoyez une commande qui gère les erreurs ou les exceptions en retournant les codes de sortie appropriés (codes de sortie autre que zéro pour un échec de la commande).

DeliveryTimedOut La commande n'a pas été fournie au nœud géré avant l'expiration du délai total. Les dépassements de délai totaux ne sont pas comptabilisés dans la limite max-errors de la commande parent, mais ils permettent de savoir si l'état de la commande parent est Success, Incomplete ou Delivery Timed Out. Il s’agit d’un statut de terminal.
ExecutionTimedOut L'automatisation de la commande a démarré sur le nœud géré, mais l'exécution de la commande ne s'est pas terminée avant l'expiration du délai d'exécution. Les expirations de délais d'exécution sont considérés comme des échecs, ce qui enverra une réponse nulle et Systems Manager quittera sortira de la tentative d'exécution de l'automatisation des commandes et signalera échec comme état.
Échec La commande n'a pas réussi sur le nœud géré. Pour un plugin, cela signifie que le code de résultat n'était pas zéro. Pour une invocation de commande, cela signifie que le code de résultat pour un ou plusieurs plugins n'était pas zéro. Les échecs d'invocation sont comptabilisés dans la limite max-errors de la commande parent. Il s’agit d’un statut de terminal.
Annulée La commande a été annulée avant de se terminer. Il s'agit d'un état final.
Undeliverable (Non livrable) La commande ne peut pas être délivrée au nœud géré. Le nœud peut ne pas exister ou ne peut pas répondre. Les appels ne pouvant pas être remis ne sont pas comptabilisés dans la limite max-errors de la commande parent, mais ils permettent de déterminer si le statut de la commande parent est Success ou Incomplete. Par exemple, si tous les appels d'une commande ont le statut Undeliverable, le statut de la commande renvoyé est Failed. Toutefois, si une commande comporte 5 appels, dont 4 renvoient le statut Undeliverable et 1 renvoie le statut Success, le statut de la commande parent est Success. Il s'agit d'un état final.
Terminated (Résilié) La commande parent atteint sa limite max-errors et les appels de commande suivants ont été annulés par le système. Il s’agit d’un statut de terminal.
InvalidPlatform La commande a été envoyée à un nœud géré qui ne correspondait pas aux plateformes requises spécifiées par le document choisi. Invalid Platform ne compte pas dans la limite maximale d'erreurs de la commande parent, mais permet de savoir si le statut de la commande parent est Success (Réussite) ou Failed (Échec). Par exemple, si tous les appels d'une commande ont le statut Invalid Platform, le statut de la commande renvoyé est Failed. Toutefois, si une commande comporte 5 appels, dont 4 renvoient le statut Invalid Platform et 1 renvoie le statut Success, le statut de la commande parent est Success. Il s’agit d’un statut de terminal.
AccessDenied L'utilisateur ou le rôle AWS Identity and Access Management (IAM) à l'origine de la commande n'a pas accès au nœud géré ciblé. Access Deniedn'est pas prise en compte dans la max-errors limite de la commande parent, mais elle contribue à déterminer si le statut de la commande parent est Success ouFailed. Par exemple, si tous les appels d'une commande ont le statut Access Denied, le statut de la commande renvoyé est Failed. Toutefois, si une commande comporte 5 appels, dont 4 renvoient le statut Access Denied et 1 renvoie le statut Success, le statut de la commande parent est Success. Il s'agit d'un état final.
Statut détaillé d'une commande
Statut Détails
En attente La commande n'a pas encore été reçue par un agent sur un nœud géré.
InProgress La commande a été envoyée au moins à un nœud géré, mais n'a pas atteint un état final sur tous les nœuds.
Delayed (Retardé) Le système tente d'envoyer la commande au nœud, mais n'a pas réussi. Le système réessaie.
Réussite La commande a été reçue par SSM Agent sur l'ensemble des nœuds gérés spécifiés ou ciblés et a retourné un code de sortie de zéro. L'ensemble des invocations de commande a atteint un état de mise hors service, et la valeur de max-errors n'a pas été atteinte. Ce statut ne signifie pas que la commande a été effectuée avec succès sur l'ensemble des nœuds gérés spécifiés ou ciblés. Il s'agit d'un état final.
Note

Pour résoudre les erreurs ou obtenir plus d'informations sur l'exécution des commandes, envoyez une commande qui gère les erreurs ou les exceptions en retournant les codes de sortie appropriés (codes de sortie autre que zéro pour un échec de la commande).

DeliveryTimedOut La commande n'a pas été fournie au nœud géré avant l'expiration du délai total. La valeur de max-errors ou d'autres appels de commande affichent le statut Delivery Timed Out. Il s'agit d'un état final.
Échec

La commande n'a pas réussi sur le nœud géré. La valeur de max-errors ou d'autres appels de commande affichent le statut Failed. Il s'agit d'un état final.

Incomplete (Incomplet) La commande a été tentée sur tous les nœuds gérés et un ou plusieurs appels n'ont pas la valeur Success. Toutefois, le nombre d'appels en échec n'est pas suffisant pour que le statut soit Failed. Il s’agit d’un statut de terminal.
Annulée La commande a été annulée avant de se terminer. Il s’agit d’un statut de terminal.
RateExceeded Le nombre de nœuds gérés ciblée par la commande a dépassé la quota du compte pour les appels en attente. Le système a annulé la commande avant de l'exécuter sur un nœud. Il s’agit d’un statut de terminal.
AccessDenied L'utilisateur ou le rôle qui initie la commande n'a pas accès au groupe de ressources ciblé. AccessDenied n'est pas pris en compte dans la limite max-errors de la commande parent, mais contribue à déterminer si le statut de la commande parent est Success ou Failed. (Par exemple, si tous les appels d'une commande ont le statut AccessDenied, alors le statut de la commande retourné est Failed. Toutefois, si une commande comporte 5 appels, dont 4 renvoient le statut AccessDenied et 1 renvoie le statut Success, le statut de la commande parent est Success.) Il s'agit d'un état final.
No Instances In Tag (Aucune instance dans la balise) La valeur ou le groupe de ressources de la paire de clés de balise ciblés par la commande ne correspondent à aucun nœud géré. Il s'agit d'un état final.

Présentation des valeurs de délai des commandes

Systems Manager applique les valeurs de délai suivantes lors de l'exécution des commandes.

Total Timeout (Délai total)

Dans la console Systems Manager, vous spécifiez la valeur du délai d'expiration dans le champ Timeout (seconds) (Délai d'expiration (secondes)). Une fois qu'une commande est envoyée, Run Command vérifie si la commande a expiré ou non. Si une commande atteint la limite d'expiration de la commande (délai total), son statut devient DeliveryTimedOut pour tous les appels ayant le statut InProgress, Pending ou Delayed.

Champ Timeout (seconds) (Délai d'expiration [secondes]) dans la console Systems Manager

Sur un plan plus technique, le délai d'expiration total (Timeout (seconds) (Délai d'expiration (secondes))) est une combinaison de deux valeurs de délai d'expiration, comme indiqué ici :

Total timeout = "Timeout(seconds)" from the console + "timeoutSeconds": "{{ executionTimeout }}" from your SSM document

Par exemple, la valeur par défaut de Timeout (seconds) (Délai d'expiration (secondes)) dans la console Systems Manager est de 600 secondes. Si vous exécutez une commande à l'aide du AWS-RunShellScript SSM document, la valeur par défaut de "timeoutSeconds« : « {{ executionTimeout }} » est de 3 600 secondes, comme indiqué dans l'exemple de document suivant :

"executionTimeout": { "type": "String", "default": "3600", "runtimeConfig": { "aws:runShellScript": { "properties": [ { "timeoutSeconds": "{{ executionTimeout }}"

Cela signifie que la commande s'exécute pendant 4 200 secondes (70 minutes) avant que le système ne définisse l'état de la commande sur DeliveryTimedOut.

Execution Timeout (Délai d'exécution)

Dans la console Systems Manager, vous spécifiez la valeur du délai d'exécution dans le champ Execution Timeout (Délai d'exécution) s'il est disponible. Tous les SSM documents ne nécessitent pas que vous spécifiiez un délai d'exécution. Le champ Execution Timeout n'est affiché que lorsqu'un paramètre d'entrée correspondant a été défini dans le SSM document. Si un délai est spécifié, la commande doit être exécutée dans ce délai.

Note

Run Command s'appuie sur la réponse terminale du document SSM Agent pour déterminer si la commande a été remise ou non à l'agent. SSM Agent doit envoyer un signal ExecutionTimedOut pour qu'une invocation ou une commande soient marquées comme ExecutionTimedOut.

Champ Execution Timeout (Délai d'exécution) de la console Systems Manager
Default Execution Timeout (Délai d'exécution par défaut)

Si un SSM document ne nécessite pas que vous spécifiiez explicitement une valeur de délai d'exécution, Systems Manager applique le délai d'exécution par défaut codé en dur.

Signalement des délais d'expiration par Systems Manager

Si Systems Manager reçoit une réponse execution timeout de l'SSM Agent sur une cible, Systems Manager marque l'invocation de commande comme executionTimeout.

Si Run Command ne reçoit pas de réponse terminale de document en provenance de l'SSM Agent, l'invocation de la commande est marquée comme deliveryTimeout.

Pour déterminer l'état du délai d'attente sur une cible, SSM Agent combine tous les paramètres et le contenu du SSM document à executionTimeout calculer. Lorsque l'SSM Agent détermine que le délai d'exécution d'une commande a expiré, il envoie executionTimeout au service.

La valeur par défaut pour Timeout (seconds) (Délai d'expiration (secondes)) est de 3 600 secondes. La valeur par défaut pour Execution timeout (Délai d'exécution) est également de 3 600 secondes. Par conséquent, le délai d'attente total par défaut pour une commande est de 7 200 secondes.

Note

SSM Agentles executionTimeout processus sont différents selon le type de SSM document et la version du document.