Comment résoudre les problèmes liés aux échecs de la commande d'exécution de Systems Manager ?

Résolution

Prérequis

Avant de pouvoir utiliser Run Command pour gérer les instances EC2, vous devez configurer une politique utilisateur AWS Identity and Access Management (IAM). La politique utilisateur est requise pour tous les utilisateurs qui exécutent des commandes. Pour vérifier votre configuration, procédez comme suit :

1. Vérifiez qu'un rôle de profil d'instance IAM pour Systems Manager est associé à vos instances EC2. Pour plus d'informations, consultez la section Configurer les autorisations d'instance pour Systems Manager.
2. Passez en revue la politique IAM créée pour le rôle ou l'utilisateur. La politique doit inclure des autorisations pour les appels d'API ec2messages car le point de terminaison est tenu d'envoyer et de recevoir des commandes.

**Remarque :**Systems Manager gère automatiquement les instances EC2 sans profil d'instance IAM lorsque vous configurez la configuration de gestion des hôtes par défaut. Toutes les instances EC2 associées doivent utiliser le service de métadonnées d'instance version 2 (IMDSv2). La configuration de gestion des hôtes par défaut est disponible dans AWS Systems Manager Agent (SSM Agent) version 3.2.582.0 ou ultérieure. Configurez les autorisations pour les appels d'API ec2messages dans la politique associée au rôle IAM, car vous avez besoin d'un point de terminaison pour envoyer et recevoir des commandes. Configurez AWS SystemsManagerDefaultEC2InstanceManagementRole comme rôle IAM par défaut. Ce rôle contient l'ensemble minimal d'autorisations nécessaires pour gérer les instances EC2 avec Systems Manager.

Résoudre les problèmes liés aux échecs d'exécution de commandes

Dans Systems Manager, sous Fleet Manager, les instances EC2 doivent être répertoriées sous Nœuds gérés et l'état du ping de l'agent SSM doit être En ligne. Si l'exécution de la commande échoue, essayez ces options de résolution des problèmes :

• Suivez les étapes de résolution décrites dans Pourquoi mon instance EC2 n'apparaît-elle pas en tant que nœud géré ou affiche-t-elle le statut « Connexion perdue » dans Systems Manager ?
• Vérifiez que l'instance utilise la dernière version de l'agent SSM.
• Lorsque Maintenance Window ou State Manager exécute la commande, confirmez que la commande est en cours d'exécution. Pour confirmer, utilisez AWS CloudTrail pour examiner la réponse de SendCommand.

Vérifiez les détails de l'état d'exécution de la commande

1. Vérifiez les détails de l'état d'exécution de la commande.
2. Ouvrez la console Systems Manager, puis choisissez Exécuter la commande dans le volet de navigation.
3. Choisissez l'ID de commande en lien hypertexte pour ouvrir la page d'état de la commande.
4. Dans la section Cibles et sorties, choisissez l'ID d'instance en lien hypertexte, puis passez en revue la sortie.

Lorsque la sortie est tronquée, connectez-vous à l'instance EC2 à l'aide de SSH, puis accédez aux répertoires suivants pour voir les détails complets de l'erreur. Notez les codes d'état de sortie, puis reportez-vous à la section Résolution des problèmes liés à la commande Exécuter du gestionnaire de systèmes pour des étapes de dépannage supplémentaires.

Pour Linux et macOS :

• /var/lib/amazon/ssm/<instance-id>/document/orchestration/<command-id>/<Plugin-name>/<Step-name>/stdout
• /var/lib/amazon/ssm/<instance-id>/document/orchestration/<command-id>/<Plugin-name>/<Step-name>/stderr

Pour Windows :

• %ProgramData%\Amazon\SSM\InstanceData\<ManagedInstance-ID>\document\orchestration\<Command-ID>\<plug-in>\<step_number.plug-in>\stdout
• %ProgramData%\Amazon\SSM\InstanceData\<ManagedInstance-ID>\document\orchestration\<Command-ID>\<plug-in>\<step_number.plug-in>\stderr

Consulter les journaux de l'agent SSM

Consultez les journaux de l'agent SSM pour plus de détails sur l'échec.

Pour Linux et macOS, recherchez les journaux dans les répertoires suivants :

• /var/log/amazon/ssm/amazon-ssm-agent.log
• /var/log/amazon/ssm/errors.log
• /var/log/amazon/ssm/audits/amazon-ssm-agent-audit-YYYY-MM-DD

Pour Windows, recherchez les journaux dans les répertoires suivants :

• %PROGRAMDATA%\Amazon\SSM\Logs\amazon-ssm-agent.log
• %PROGRAMDATA%\Amazon\SSM\Logs\errors.log
• %PROGRAMDATA%\Amazon\SSM\Logs\audits\amazon-ssm-agent-audit-YYYY-MM-DD

Si les journaux de l'agent SSM ne fournissent pas les informations dont vous avez besoin pour résoudre l'erreur, autorisez la journalisation du débogage à reproduire le problème.

Informations connexes

Documents d'AWS Systems Manager

Configuration d'AWS Systems Manager