Share Your AWS re:Post Experience - Quick 3 Question Survey
Help us improve AWS re:Post! We're interested in understanding how you use re:Post and its impact on your AWS journey. Please take a moment to complete our brief 3-question survey.
Comment puis-je résoudre les problèmes liés à l’agent Systems Manager qui est bloqué au démarrage ou qui ne démarre pas ?
Je souhaite déterminer pourquoi AWS Systems Manager Agent (SSM Agent) est bloqué au démarrage ou ne démarre pas.
Brève description
Une instance gérée est une instance Amazon EC2 configurée pour être utilisée avec le Systems Manager. Les instances gérées peuvent utiliser les services du Systems Manager tels qu’Exécuter la commande, Gestionnaire de correctifs et Gestionnaire de session.
Assurez-vous que votre instance Amazon Elastic Compute Cloud (Amazon EC2) répond aux conditions préalables suivantes pour être une instance gérée :
- Le SSM Agent est installé et en cours d’exécution sur l’instance.
- L’instance est connectée au service de métadonnées de l’instance.
- L’instance est connectée aux points de terminaison de Systems Manager à l’aide du SSM Agent.
- Le rôle AWS Identity and Access Management (IAM) approprié est associé à l’instance.
Le SSM Agent ne démarre pas lorsque ces conditions préalables ne sont pas remplies.
Pour les versions 3.1.501.0 et ultérieures du SSM Agent, vous pouvez utiliser l'outil ssm-cli pour déterminer si une instance répond à ces exigences. Cet outil vous permet de déterminer pourquoi une instance EC2 en cours d’exécution ne figure pas dans la liste des instances gérées de Systems Manager.
Si votre instance n’apparaît pas en tant qu’instance gérée dans la console Systems Manager, consultez les journaux du SSM Agent pour un dépannage plus approfondi.
- Vous pouvez trouver les journaux du SSM Agent pour Linux à l’adresse /var/log/amazon/ssm.
- Vous pouvez trouver les journaux du SSM Agent pour Windows à l’adresse %PROGRAMDATA%\Amazon\SSM\Logs.
Remarque : si l’instance ne rapporte pas à Systems Manager, essayez de vous connecter via RDP (Windows) ou SSH (Linux) pour collecter les journaux. Si vous ne parvenez toujours pas à vous connecter, arrêtez l’instance et détachez le volume racine. Ensuite, attachez le volume racine à une autre instance de la même zone de disponibilité en tant que volume secondaire pour obtenir les journaux.
Résolution
Remarque : si des erreurs surviennent lors de l’exécution des commandes de l’Interface de la ligne de commande AWS CLI, vérifiez que vous utilisez la version la plus récente d’AWS CLI.
Assurez-vous d’avoir installé la dernière version du SSM Agent
Il est recommandé d’utiliser la dernière version du SSM Agent.
Pour Linux, consultez la section Installation manuelle du SSM Agent sur des instances EC2 pour Linux.
Pour Windows, consultez la section Installation manuelle du SSM Agent sur des instances EC2 pour Windows Server.
Vérifiez la connectivité au service de métadonnées de l’instance
Remarque : cette connectivité est requise uniquement pour une instance EC2 et non pour une activation hybride.
Le SSM Agent s’appuie sur les métadonnées de l’instance EC2 pour fonctionner correctement. Le SSM Agent peut accéder aux métadonnées de l’instance à l’aide du service de métadonnées d’instance version 1 (IMDSv1) ou du service de métadonnées d’instance version 2 (IMDSv2). Assurez-vous que votre instance peut accéder à l’adresse IPv4 du service de métadonnées d’instance : 169.254.169.254.
Pour vérifier la connectivité au service de métadonnées d’instance, exécutez la commande suivante depuis votre instance EC2 :
Linux :
telnet 169.254.169.254 80 or curl -I http://169.254.169.254/latest/meta-data/
Windows :
curl http://169.254.169.254/latest/meta-data/ or Test-NetConnection 169.254.169.254 -port 80
Si votre instance ne peut pas accéder aux métadonnées, assurez-vous que les métadonnées sont activées.
Pour les instances EC2 existantes, procédez comme suit pour vérifier si les métadonnées sont activées :
- Ouvrez la console Amazon EC2.
- Dans le volet de navigation, choisissez Instances.
- Sélectionnez votre instance.
- Choisissez Actions, Paramètres de l’instance, Options de modification des métadonnées de l’instance.
- Dans la boîte de dialogue Modifier les options des métadonnées de l’instance, vérifiez si le service de métadonnées de l’instance est activé.
Vous pouvez également utiliser la commande describe-instances pour vérifier si le service de métadonnées d’instance est activé :
aws ec2 describe-instances --query "Reservations[*].Instances[*].MetadataOptions" --instance-ids i-012345678910
Le résultat ressemble à ce qui suit :
[ [ { "State": "applied", "HttpTokens": "optional", "HttpPutResponseHopLimit": 1, "HttpEndpoint": "enabled", "HttpProtocolIpv6": "disabled", "InstanceMetadataTags": "disabled" } ] ]
Le champ HttpEndpoint dans la sortie précédente indique si les métadonnées sont activées.
Si l’accès aux métadonnées est désactivé, activez-le.
Si un proxy est configuré dans l’instance, assurez-vous que l’instance contourne l’adresse IP des métadonnées (169.254.169.254). Pour plus d’informations, consultez les guides de l’utilisateur suivants :
Linux : Configuration du SSM Agent pour utiliser un proxy (Linux)
Windows : Configurer le SSM Agent pour utiliser un proxy pour les instances de Windows Server
Pour Windows, vérifiez l’itinéraire spécifique vers les métadonnées (169.254.169.254).
Dans PowerShell, exécutez les commandes route print et ipconfig /all. Vérifiez ensuite la sortie des métadonnées :
Network Address Netmask Gateway Address 169.254.169.254 255.255.255.255 <Subnet Router Address>
Vérifiez que le champ Adresse de la passerelle dans la sortie correspond à la passerelle par défaut pour l’interface réseau principale de l’instance.
Si l’itinéraire n’est pas présent ou si le champ Adresse de la passerelle ne correspond pas, procédez comme suit :
- Vérifiez que la dernière version d’EC2Config (Windows Server 2012R2 et versions antérieures) ou d’EC2Launch (Windows Server 2016 ou version ultérieure) est installée sur l’instance.
- Pour appliquer l’itinéraire à l’instance, redémarrez le service EC2Config.
- Si les itinéraires sont corrects, mais que l’instance ne parvient toujours pas à récupérer les métadonnées, passez en revue la configuration du pare-feu Windows, du pare-feu tiers et de l’antivirus de votre instance. Vérifiez que le trafic vers 169.254.169.254 n’est pas explicitement refusé.
Pour réinitialiser manuellement les itinéraires de métadonnées, procédez comme suit :
Remarque : ces modifications configurées sont immédiatement renseignées. Il n’est pas nécessaire de redémarrer l’instance pour que les modifications prennent effet.
-
Exécutez les commandes suivantes pour supprimer les itinéraires de métadonnées existants de la table de routage :
route delete 169.254.169.123 route delete 169.254.169.249 route delete 169.254.169.250 route delete 169.254.169.251 route delete 169.254.169.252 route delete 169.254.169.253 route delete 169.254.169.254
-
Exécutez la commande suivante :
ipconfig /all
-
Notez l’adresse IP de la passerelle par défaut renvoyée par la commande à l’étape 2.
-
Exécutez la commande suivante. Remplacez DefaultGatewayIP par l’adresse IP que vous avez récupérée à l’étape 3.
route -p add 169.254.169.123 MASK 255.255.255.255 DefaultGatewayIP route -p add 169.254.169.249 MASK 255.255.255.255 DefaultGatewayIP route -p add 169.254.169.250 MASK 255.255.255.255 DefaultGatewayIP route -p add 169.254.169.251 MASK 255.255.255.255 DefaultGatewayIP route -p add 169.254.169.252 MASK 255.255.255.255 DefaultGatewayIP route -p add 169.254.169.253 MASK 255.255.255.255 DefaultGatewayIP route -p add 169.254.169.254 MASK 255.255.255.255 DefaultGatewayIP
-
Redémarrez le SSM Agent.
Vérifiez la connectivité au points de terminaison de Systems Manager
La meilleure méthode pour vérifier cette connectivité dépend de votre système d’exploitation. Pour obtenir la liste des points de terminaison de Systems Manager par région, consultez la section Points de terminaison et quotas d’AWS Systems Manager.
**Remarque :**dans les exemples suivants, le point de terminaison ssmmessages est requis uniquement pour AWS Systems Manager Session Manager.
Pour les instances Linux EC2, exécutez les commandes telnet ou netcat pour vérifier la connectivité aux points de terminaison sur le port 443.
Telnet
telnet ssm.RegionID.amazonaws.com 443 telnet ec2messages.RegionID.amazonaws.com 443 telnet ssmmessages.RegionID.amazonaws.com 443
Assurez-vous de remplacer RegionID par votre ID de région AWS.
Si la connexion est établie, vous obtenez une sortie similaire à la suivante :
root@111800186:~# telnet ssm.us-east-1.amazonaws.com 443 Trying 52.46.141.158... Connected to ssm.us-east-1.amazonaws.com. Escape character is '^]'. To exit from telnet, hold down the Ctrl key and press the ] key. Enter quit, and then press Enter.
Netcat
nc -vz ssm.RegionID.amazonaws.com 443 nc -vz ec2messages.RegionID.amazonaws.com 443 nc -vz ssmmessages.RegionID.amazonaws.com 443
Remarque : Netcat n’est pas préinstallé sur les instances Amazon EC2. Pour installer Netcat manuellement, consultez Ncat sur le site Web de Nmap.
Pour les instances Windows EC2, exécutez les commandes Windows PowerShell suivantes pour vérifier la connectivité aux points de terminaison sur le port 443 :
Test-NetConnection ssm.RegionID.amazonaws.com -port 443 Test-NetConnection ec2messages.RegionID.amazonaws.com -port 443 Test-NetConnection ssmmessages.RegionID.amazonaws.com -port 443
Si la connexion est établie, vous obtenez une sortie similaire à la suivante :
PS C:\Users\ec2-user> Test-NetConnection ssm.us-east-1.amazonaws.com -port 443 ComputerName : ssm.us-east-1.amazonaws.com RemoteAddress : 52.46.145.233 RemotePort : 443 InterfaceAlias : Ethernet SourceAddress : 10.35.218.225 TcpTestSucceeded : True
Vérifiez le rôle IAM du SSM Agent
Le SSM Agent nécessite certaines autorisations de l’IAM pour passer les appels de l’API Systems Manager. Vous pouvez gérer ces autorisations à l’aide de l’une des approches suivantes :
- La configuration de gestion des hôtes par défaut permet à Systems Manager de gérer automatiquement vos instances Amazon EC2. Il permet de gérer les instances sans utiliser de profils d’instance. Cette configuration garantit que Systems Manager est autorisé à gérer toutes les instances de la région et du compte.
- Vous pouvez accorder l’accès au niveau de l’instance à l’aide d’un profil d’instance IAM. Un profil d’instance est un conteneur qui transmet les informations relatives au rôle IAM à une instance lors de son lancement. Pour plus d’informations, consultez la section Configuration alternative.
Informations connexes
Rendre un volume Amazon EBS disponible pour une utilisation sous Linux
Rendre un volume Amazon EBS disponible pour une utilisation sous Windows

Contenus pertinents
- demandé il y a un anlg...
- demandé il y a 9 moislg...
- demandé il y a un anlg...
- demandé il y a un anlg...
- demandé il y a un anlg...
- AWS OFFICIELA mis à jour il y a 4 mois
- AWS OFFICIELA mis à jour il y a 2 ans