Comment puis-je résoudre les problèmes d'une association State Manager ayant échoué ou qui est bloquée en attente ?

Dernière mise à jour : 24/03/2021

J'ai créé une association State Manager planifiée pour s'exécuter sur mon instance Amazon Elastic Compute Cloud (Amazon EC2) gérée. Toutefois, l'association a échoué ou est bloquée en attente. Comment résoudre ce problème ?

Résolution

L'association AWS Systems Manager State Manager est une configuration affectée à vos instances gérées. La configuration définit l'état que vous souhaitez conserver sur vos instances.

Lorsque vous créez une association State Manager, Systems Manager lie les informations de planification, de cibles, de document et de paramètre que vous spécifiez aux instances gérées. Le statut de l'association est initialement en attente tandis que le système essaie d'atteindre toutes les cibles et d'appliquer immédiatement l'état spécifié dans l'association.

Résoudre les problèmes d'une association bloquée en attente ou ayant échoué

Si l'association State Manager reste bloquée en attente ou échoue, vérifiez d'abord que la dernière version de l'agent SSM est bien installée.

Vérifiez ensuite l'état de la ressource dans laquelle l'association est appliquée et affichez l'historique pour confirmer s'il y a eu des appels.

  1. Depuis la page des associations State Manager de la console Systems Manager, choisissez le lien hypertexte Association id (ID d'association) pour l'association bloquée en attente ou ayant échoué.
  2. Choisissez l'onglet Execution history (Historique de l'exécution) pour afficher l'historique des appels.
  3. Si l'historique répertorie les appels, choisissez le lien hypertexte Execution id (ID d'exécution) pour afficher le type de ressource, son statut et d'autres détails. Ensuite, passez à la section Identifier la cause du problème du présent article.

Si aucun appel n'est répertorié dans l'historique, vérifiez que l'instance est une instance gérée. À partir de la console Systems Manager, l'instance doit être répertoriée sous Managed instances (Instances gérées) et le statut ping de l'agent SSM doit être Online (En ligne).

Si votre instance n'apparaît pas sous Managed instances (Instances gérées), consultez Pourquoi mon instance EC2 n'apparaît-elle pas sous Instances gérées dans la console Systems Manager ?

Si le statut ping de l'agent SSM est Connection Lost (Connexion perdue), consultez Comment puis-je résoudre une instance gérée Systems Manager dont la connexion a été perdue ?

Identifier la cause du problème

Si l'historique répertorie les appels, depuis la page des cibles d'exécution d'association d'ID d'exécution, sélectionnez l'instance cible Resource ID (ID de ressource), puis choisissez Output (Sortie). La sortie affiche des détails et un message d'erreur indiquant les raisons de l'échec de l'association.

Remarque : la sortie diffère selon le document Systems Manager que vous utilisez. Pour plus d'informations, consultez les documents AWS Systems Manager.

Consulter les journaux de l'agent SSM

Pour plus de détails sur l'échec du document Run Command, consultez les journaux de l'agent SSM :

Pour Linux et macOS, ces journaux se trouvent 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-AAAA-MM-JJ

Remarque : les fichiers stderr et stdout de l'agent SSM figurent dans le répertoire /var/lib/amazon/ssm.

Sous Windows, ces journaux se trouvent 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-AAAA-MM-JJ

Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?