Comment utiliser les journaux de l'agent SSM pour résoudre les problèmes liés à l'agent SSM dans mon instance gérée ?

Lecture de 9 minute(s)
0

AWS Systems Manager Agent (SSM Agent) ne parvient pas à s'exécuter correctement, mais je ne sais pas comment résoudre le problème à l'aide des journaux SSM Agent.

Brève description

L'agent SSM s'exécute sur votre instance Amazon Elastic Compute Cloud (Amazon EC2) gérée et traite les demandes provenant du service AWS Systems Manager. L'agent SSM exige que les conditions suivantes soient remplies :

  • L'agent SSM doit se connecter aux points de terminaison du service requis.
  • L'agent SSM nécessite des autorisations AWS Identity et Access Management (IAM) pour appeler les appels d'API Systems Manager.
  • Amazon EC2 doit utiliser des informations d'identification valides provenant du profil d'instance IAM.

Si l'une de ces conditions n'est pas remplie, l'agent SSM ne s'exécute pas correctement.

Pour identifier la cause première de la défaillance de l'agent SSM, consultez les journaux de l'agent SSM aux emplacements suivants :

Linux

/var/log/amazon/ssm/amazon-ssm-agent.log
/var/log/amazon/ssm/errors.log

Windows

%PROGRAMDATA%\Amazon\SSM\Logs\amazon-ssm-agent.log
%PROGRAMDATA%\Amazon\SSM\Logs\errors.log

Remarque : l'agent SSM étant fréquemment mis à jour avec de nouvelles fonctionnalités, il est recommandé de configurer des mises à jour automatiques pour l'agent SSM.

Résolution

Commencez par examiner les journaux et déterminez si le problème est dû à l'absence de connexions aux points de terminaison, à des autorisations manquantes ou à des informations d'identification manquantes. Suivez ensuite les étapes de dépannage correspondant à votre problème.

L'agent SSM ne peut pas communiquer avec les points de terminaison requis

L'agent SSM ne peut pas accéder au service de métadonnées

Lorsque l'agent SSM ne parvient pas à accéder au service de métadonnées, il ne peut pas non plus localiser les informations de région AWS, le rôle IAM ou l'ID d'instance provenant de ce service. Dans ce cas, un message d'erreur similaire au suivant s'affiche dans les journaux de l'agent SSM :

« INFO- Impossible de récupérer l'ID de l'instance. Les données du coffre sont vides. RequestError : échec de l'envoi de la demande causé par : Get http://169.254.169.254/latest/meta-data/instance-id »

La raison la plus courante de cette erreur est l'utilisation d'un proxy pour les connexions Internet sortantes depuis votre instance sans configurer l'agent SSM pour un proxy. Assurez-vous de configurer l'agent SSM pour utiliser un proxy.

Sur les instances Windows, cette erreur peut également se produire en raison d'une route réseau persistante mal configurée lorsque vous utilisez une AMI personnalisée pour lancer votre instance. Vous devez vérifier que la route de l'adresse IP du service de métadonnées pointe vers la passerelle par défaut correcte.

Pour vérifier si les métadonnées sont activées pour votre instance, exécutez la commande suivante dans l'interface de ligne de commande AWS (AWS CLI). Assurez-vous de remplacer i-1234567898abcdef0 par votre ID d'instance :

Remarque : en cas d'erreurs lors de l'exécution de commandes AWS CLI, vérifiez que vous utilisez la version la plus récente d'AWS CLI.

aws ec2 describe-instances --instance-ids i-1234567898abcdef0 --query 'Reservations[*].Instances[*].MetadataOptions'

Vous recevez un résultat similaire au suivant :

[
  [{
    "State": "applied",
    "HttpTokens": "optional",
    "HttpPutResponseHopLimit": 1,
    "HttpEndpoint": "enabled",
    "HttpProtocolIpv6": "disabled",
    "InstanceMetadataTags": "disabled"
  }]
]

Dans cette sortie, « HttpEnpoint » : « enabled » indique que les métadonnées sont activées pour votre instance.

Si les métadonnées ne sont pas activées, vous pouvez les activer à l'aide de la commande aws ec2 modify-instance-metadata-options. Pour plus d'informations, consultez Modifier les options de métadonnées d'instance pour les instances existantes.

L'agent SSM ne peut pas atteindre les points de terminaison du service Systems Manager

Si l'agent SSM ne parvient pas à se connecter aux points de terminaison du service, l'agent SSM échoue. L'agent SSM doit établir une connexion sortante avec les appels d'API du service Systems Manager suivants sur le port 443 :

  • Point de terminaison SSM : ssm.REGION.amazonaws.com
  • Point de terminaison de messagerie EC2 : ec2messages.REGION.amazonaws.com
  • Point de terminaison de messagerie SSM : ssmmessages.REGION.amazonaws.com

Remarque : l'agent SSM utilise les informations de région que le service de métadonnées d'instance récupère pour remplacer la valeur RÉGION dans ces points de terminaison.

Lorsque l'agent SSM ne parvient pas à se connecter aux points de terminaison de Systems Manager, des messages d'erreur similaires aux suivants s'affichent dans les journaux de l'agent SSM :

« Erreur [HealthCheck] lors de l'appel d'API AWS. Détails de l'erreur - RequestError : échec de l'envoi de la demande causé par : Post https://ssm.ap-southeast-2.amazonaws.com/ : dial tcp 172.31.24.65:443 : délai d'attente des entrées/sorties »

« DEBUG [MessagingDeliveryService] RequestError: échec de l’envoi de la demandé causé par : Post https://ec2messages.ap-southeast-2.amazonaws.com/ : net/http : demande annulée en attendant la connexion (Client.Timeout dépassé en attendant les en-têtes) »

Voici quelques raisons courantes pour lesquelles l'agent SSM ne peut pas se connecter aux points de terminaison de l'API Systems Manager sur le port 443 :

  • Les règles des groupes de sécurité de la sortie des instances n'autorisent pas les connexions sortantes sur le port 443.
  • Les règles des groupes de sécurité d'entrée et de sortie du cloud privé virtuel (VPC) n'autorisent pas les connexions entrantes et sortantes vers le point de terminaison de l'interface VPC sur le port 443.
  • Lorsque l'instance se trouve dans un sous-réseau public, les règles de la table de routage ne sont pas configurées pour diriger le trafic via une passerelle Internet.
  • Lorsque l'instance réside dans un sous-réseau privé, les règles de la table de routage ne sont pas configurées pour diriger le trafic via une passerelle NAT ou un point de terminaison d’un VPC.
  • Si les règles de la table de routage sont configurées pour utiliser un proxy pour toutes les connexions sortantes, l'agent SSM n'est pas configuré pour utiliser un proxy.

L'agent SSM n'est pas autorisé à appeler les appels d'API Systems Manager requis

L'agent SSM n'a pas pu s'enregistrer comme étant en ligne sur Systems Manager car l'agent SSM n'est pas autorisé à effectuer des appels d'API UpdateInstanceInformation vers le service.

L'appel d'API UpdateInstanceInformation doit maintenir une connexion avec l'agent SSM afin que le service sache que l'agent SSM fonctionne comme prévu. L'agent SSM appelle le service Systems Manager dans le cloud toutes les cinq minutes pour fournir des informations sur la surveillance de l’état. Si l'agent SSM ne dispose pas des autorisations IAM correctes, un message d'erreur s'affiche dans les journaux de l'agent SSM.

Si l'agent SSM utilise les autorisations IAM incorrectes, une erreur similaire à la suivante s'affiche :

« ERREUR [InstanceId=I-XXXXX] Erreur [HealthCheck] lors de l'appel d'API AWS. Détails de l'erreur - AccessDeniedException : L'utilisateur : arn:aws:sts : :xxx:Assumed-Role/xxx /I-XXXXXX n'est pas autorisé à exécuter : SSM:UpdateInstanceInformation sur la ressource : arn:AWS:ec2:AP-Southeast-2:XXXXXXXXX:Instance/I-XXXXX
code d'état : 400, numéro de demande : XXXXXXXX-XXXX-XXXXXXX
INFO [InstanceId=I-XXXX] [HealthCheck] augmente le nombre d'erreurs de 1 »

Si l'agent SSM ne dispose d'aucune autorisation IAM, une erreur similaire à la suivante s'affiche :

« ERREUR [InstanceId=I-xxxxxxx] [HealthCheck] Erreur lors de l'appel d'API AWS. Détails de l'erreur - NoCredentialProviders : aucun fournisseur valide dans la chaîne. Obsolète. Pour la messagerie verbeuse, voir aws.Config.CredentialsChainVerboseErrors
08-05-2018 10:58:39 INFO [instanceId=I-xxxxxxx] [HealthCheck] augmente le nombre d'erreurs de 1 »

Vérifiez que le rôle IAM associé à l'instance contient les autorisations requises pour permettre à une instance d'utiliser les fonctionnalités de base du service Systems Manager. Ou, si aucun rôle de profil d'instance n'est déjà associé, associez un rôle de profil d'instance et incluez les autorisations AmazonSSMManagedInstanceCore.

Pour plus d'informations sur les autorisations IAM requises pour Systems Manager, consultez la section Considérations de politique supplémentaires pour les instances gérées.

Limitation des appels de l'API Systems Manager

Un volume élevé d'instances gérées exécutant l'agent SSM effectuent des appels d'API UpdateInstanceInformation simultanés, ces appels peuvent alors être limités.

Si l'appel d'API UpdateInstanceInformation pour votre instance est limité, des messages d'erreur similaires aux suivants s'affichent dans les journaux de l'agent SSM :

« INFO [HealthCheck] HealthCheck rapporte l'état de santé de l'agent.
ERREUR [HealthCheck] lors de l'appel d'API AWS. Détails de l'erreur - ThrottlingException : taux dépassé
code d'état : 400, numéro de demande : XXXXX-XXXXX-XXXX
INFO [HealthCheck] augmente le nombre d'erreurs de 1 »

Suivez les étapes de dépannage suivantes pour éviter les erreurs ThrottlingException :

  • Réduisez la fréquence des appels d'API.
  • Implémentez de nouvelles tentatives après erreur et des interruptions exponentielles lorsque vous effectuez des appels d'API.
  • Échelonnez les intervalles des appels d'API pour qu'ils ne s'exécutent pas tous simultanément.
  • Demandez une augmentation de la limite de limitation pour les appels d'API UpdateInstanceInformation.

Amazon EC2 ne peut pas présumer que les informations d'identification du profil d'instance IAM sont valides

Si Amazon EC2 ne peut pas assumer le rôle IAM, un message similaire à l'exemple suivant s'affiche dans les journaux de l'agent SSM :

2023-01-25 09:56:19 ERROR [CredentialRefresher] Retrieve credentials produced error: no valid credentials could be retrieved for ec2 identity
2023-01-25 09:56:19 INFO [CredentialRefresher] Sleeping for 1s before retrying retrieve credentials
2023-01-25 09:56:20 ERROR [CredentialRefresher] Retrieve credentials produced error: no valid credentials could be retrieved for ec2 identity
2023-01-25 09:56:20 INFO [CredentialRefresher] Sleeping for 2s before retrying retrieve credentials
2023-01-25 09:56:22 ERROR [CredentialRefresher] Retrieve credentials produced error: no valid credentials could be retrieved for ec2 identity
2023-01-25 09:56:22 INFO [CredentialRefresher] Sleeping for 4s before retrying retrieve credentials
2023-01-25 09:56:26 ERROR [CredentialRefresher] Retrieve credentials produced error: no valid credentials could be retrieved for ec2 identity
2023-01-25 09:56:26 INFO [CredentialRefresher] Sleeping for 9s before retrying retrieve credentials
2023-01-25 09:56:35 ERROR [CredentialRefresher] Retrieve credentials produced error: no valid credentials could be retrieved for ec2 identity
2023-01-25 09:56:35 INFO [CredentialRefresher] Sleeping for 17s before retrying retrieve credentials
2023-01-25 09:56:52 ERROR [CredentialRefresher] Retrieve credentials produced error: no valid credentials could be retrieved for ec2 identity
2023-01-25 09:56:52 INFO [CredentialRefresher] Sleeping for 37s before retrying retrieve credentials

Si vous essayez de récupérer des métadonnées à partir de l'instance EC2, vous verrez également une erreur similaire à la suivante :

# curl http://169.254.169.254/latest/meta-data/iam/security-credentials/profile-name
{
  "Code" : "AssumeRoleUnauthorizedAccess",
  "Message" : "EC2 cannot assume the role profile-name. Please see documentation at https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-ec2.html#troubleshoot_iam-ec2_errors-info-doc.",
  "LastUpdated" : "2023-01-25T09:57:56Z"
}

Remarque : dans cet exemple,profile-name est le nom du profil d'instance.

Pour résoudre cette erreur, vérifiez la politique de confiance associée au rôle IAM. Dans la politique, vous devez spécifier Amazon EC2 en tant que service autorisé à assumer le rôle IAM. Mettez à jour votre politique IAM via l'API UpdateAssumeRolePolicy afin qu'elle ressemble à l'exemple suivant :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": ["ec2.amazonaws.com"]
      },
      "Action": ["sts:AssumeRole"]
    }
  ]
}

Pour plus d'informations, voir Le document iam/security-credentials/ [role-name] indique le « Code » : « AssumeRoleUnauthorizedAccess ».


AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an