• Le AWS Systems Manager CloudWatch tableau de bord ne sera plus disponible après le 30 avril 2026. Les clients peuvent continuer à utiliser CloudWatch la console Amazon pour consulter, créer et gérer leurs CloudWatch tableaux de bord Amazon, comme ils le font aujourd'hui. Pour plus d'informations, consultez la documentation [ Amazon CloudWatch Dashboard](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
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.
# Résolution des problèmes SSM Agent
Si vous rencontrez des problèmes lors de l'exécution des opérations sur vos nœuds gérés, il se peut qu'il y ait un problème avec AWS Systems Manager Agent (SSM Agent). Utilisez les informations suivantes pour vous permettre de visualiser les fichiers journaux de l'SSM Agent et dépanner l'agent. Si votre agent ne semble pas répondre ou s’il a une fréquence de communication réduite, consultez [Compréhension SSM Agent hivernation](ssm-agent-technical-details.md#ssm-agent-hibernation).
**Topics**
+ [SSM Agent est obsolète](#ssm-agent-out-of-date)
+ [Résoudre les problèmes liés à l'utilisation SSM Agent fichiers journaux](#systems-manager-ssm-agent-log-files)
+ [L'observateur de fichiers échoue avec un `trop grand nombre de fichiers ouverts` (Linux)](#ssm-agent-troubleshooting-file-watcher-too-many-open-files)
+ [Les fichiers journaux de l'agent ne tournent pas (Windows)](#systems-manager-ssm-agent-troubleshooting-log-rotation)
+ [Impossible de se connecter aux points de terminaison SSM](#systems-manager-ssm-agent-troubleshooting-endpoint-access)
+ [Vérification de votre configuration VPC](#agent-ts-vpc-configuration)
+ [Vérifiez les attributs de votre VPC DNS-related](#agent-ts-dns-attributes)
+ [Vérification des règles d’entrée sur les groupes de sécurité de point de terminaison](#agent-ts-ingress-egress-rules)
+ [Utiliser `ssm-cli` pour résoudre les problèmes de disponibilité des nœuds gérés](#agent-ts-ssm-cli)
## SSM Agent est obsolète
Une nouvelle version de SSM Agent est lancée chaque fois que de nouveaux outils sont ajoutés à Systems Manager ou que des mises à jour sont apportées aux outils existants. Le fait de ne pas utiliser la dernière version de l’agent peut empêcher votre nœud géré d’utiliser divers outils et fonctionnalités de Systems Manager. C'est pourquoi nous vous recommandons d'automatiser le processus permettant de maintenir SSM Agent à jour sur vos machines. Pour plus d’informations, consultez [Automatiser les mises à jour de SSM Agent](ssm-agent-automatic-updates.md). Inscrivez‑vous sur la page [SSM Agent Release Notes](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) du site Web de GitHub pour recevoir des notifications sur les mises à jour de SSM Agent.
## Résoudre les problèmes liés à l'utilisation SSM Agent fichiers journaux
SSM Agent consigne des informations dans les fichiers suivants. Les informations de ces fichiers peuvent également vous aider à résoudre les problèmes. Pour de plus amples informations sur les fichiers journaux de l'SSM Agent, notamment l'activation de la journalisation du débogage, veuillez consulter [Visualisation SSM Agent journaux](ssm-agent-logs.md).
**Note**
Si vous choisissez d'afficher ces journaux à l'aide de l'Explorateur de fichiers Windows, n'oubliez pas d'activer l'affichage des fichiers masqués et fichiers système dans les options de dossier.
**Sous Windows**
+ `%PROGRAMDATA%\Amazon\SSM\Logs\amazon-ssm-agent.log`
+ `%PROGRAMDATA%\Amazon\SSM\Logs\errors.log`
**Sous Linux et macOS**
+ `/var/log/amazon/ssm/amazon-ssm-agent.log`
+ `/var/log/amazon/ssm/errors.log`
Pour les nœuds gérés Linux, vous pouvez trouver de plus amples informations dans le fichier `messages` rédigé dans le répertoire suivant : `/var/log`.
Pour en savoir plus sur le dépannage à l'aide des journaux d'agents, consultez la rubrique [Comment puis-je utiliser les journaux SSM Agent pour résoudre des problèmes liés à SSM Agent dans mon instance gérée ?](https://repost.aws/knowledge-center/ssm-agent-logs) dans le * Centre de connaissances AXS re:Post AWS *.
## L'observateur de fichiers échoue avec un `trop grand nombre de fichiers ouverts` (Linux)
SSM Agentutilise des observateurs de fichiers pour la communication entre les processus et les processus de travail. Ce mécanisme peut être utilisé par plusieurs opérations de Systems Manager, y compris les associations et les Session Manager sessions. Si l'agent ne parvient pas à créer un nouvel observateur de fichiers, le journal de l'agent peut contenir une entrée similaire à la suivante :
```
ERROR [NewFileWatcherChannel @ filewatcherchannel.go.104] ... filewatcher listener encountered error when start watcher: too many open files
```
Selon le système d'exploitation, le texte final peut être `too many open file` ou`too many open files`. Pour cette signature spécifique, la principale cause est l'épuisement de la limite d'instances d'initialisation d'ID utilisateur (UID) Linux. L'échec se produit lorsque l'agent crée l'observateur, avant qu'il n'ajoute un chemin vers l'observateur.
Utilisez la commande suivante sur le nœud géré pour inspecter la limite actuelle d'instances inotify :
```
sudo sysctl fs.inotify.max_user_instances
```
La recommandation prise en charge pour cette condition est de `fs.inotify.max_user_instances` définir sur`8192`. Pour appliquer la valeur au système en cours d'exécution, utilisez la commande suivante :
```
sudo sysctl -w fs.inotify.max_user_instances=8192
```
Pour conserver la valeur, créez un fichier de configuration sysctl et chargez-le :
```
printf '%s\n' 'fs.inotify.max_user_instances=8192' | sudo tee /etc/sysctl.d/99-amazon-ssm-agent.conf
sudo sysctl -p /etc/sysctl.d/99-amazon-ssm-agent.conf
```
**Important**
Dimensionnez les limites du système d'exploitation en fonction de la charge de travail sur le nœud géré et des politiques du système d'exploitation de votre organisation. N'appliquez pas de valeurs limites indépendantes sans évaluer les autres processus qui s'exécutent sous le même UID.
Le `fs.inotify.max_user_watches` paramètre limite le nombre de chemins que les instances inotify peuvent surveiller. Il est différent `fs.inotify.max_user_instances` et n'a normalement pas besoin d'être modifié pour cet échec de création d'observateurs. Modifiez-le uniquement lorsque les diagnostics de votre système d'exploitation indiquent que la limite de visionnage est dépassée.
**Note**
Traitez les limites de fichiers ouverts, y compris `nofile` les limites du shell et leurs `systemd` `LimitNOFILE` paramètres, ainsi que les paramètres du système `fs.nr_open` et `fs.file-max` appliquez-les aux autres conditions d'épuisement des descripteurs de fichiers. Ils n'augmentent pas la limite d'instances inotify par UID et ne résolvent pas cette signature spécifique. `NewFileWatcherChannel`
## Les fichiers journaux de l'agent ne tournent pas (Windows)
Si vous spécifiez une rotation des fichiers journaux basée sur la date dans le fichier seelog.xml (sur les nœuds gérés Windows Server) et que les journaux ne tournent pas, spécifiez le paramètre `fullname=true`. Voici un exemple de fichier de configuration seelog.xml pour lequel le paramètre `fullname=true` est spécifié.
```
```
## Impossible de se connecter aux points de terminaison SSM
SSM Agent doit autoriser le trafic sortant HTTPS (port 443) vers les points de terminaison suivants :
+ `ssm.{{region}}.amazonaws.com`
+ `ssmmessages.{{region}}.amazonaws.com`
{{region}}représente l'identifiant d'une zone Région AWS prise en charge par AWS Systems Manager, par exemple `us-east-2` pour la région USA Est (Ohio). Pour obtenir la liste des {{region}} valeurs prises en charge, consultez la ** colonne ** Région des points de terminaison du service [ Systems Manager ](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) dans le *Référence générale d'Amazon Web Services*.
**Note**
Avant 2024, `ec2messages.{{region}}.amazonaws.com` était également requis. Pour les Régions AWS lancements avant 2024, l'autorisation du trafic vers `ssmmessages.{{region}}.amazonaws.com` est toujours requise mais facultative`ec2messages.{{region}}.amazonaws.com`.
Pour les régions lancées à partir de 2024, l’autorisation du trafic vers `ssmmessages.{{region}}.amazonaws.com` est requise, mais les points de terminaison `ec2messages.{{region}}.amazonaws.com` ne sont pas pris en charge pour ces régions.
SSM Agentne fonctionnera pas s'il ne peut pas communiquer avec les points de terminaison précédents, comme décrit, même si vous utilisez AWS provided Amazon Machine Images (AMIs) comme Amazon Linux 2 ou Amazon Linux 2023. Votre configuration réseau doit avoir un accès Internet ouvert, ou bien des points de terminaison de cloud privé virtuel (VPC) personnalisés doivent être configurés. Si vous ne prévoyez pas de créer un point de terminaison de VPC personnalisé, vérifiez vos passerelles Internet ou NAT. Pour plus d'informations sur la gestion des points de terminaison de VPC, consultez [Renforcement de la sécurité des instances EC2 à l’aide des points de terminaison de VPC pour Systems Manager](setup-create-vpc.md).
## Vérification de votre configuration VPC
Si vous utilisez un cloud privé virtuel (VPC) pour gérer des instances EC2 avec Systems Manager, vos points de terminaison VPC doivent être correctement configurés pour `ssm.{{region}}.amazonaws.com``ssmmessages.{{region}}.amazonaws.com`, et dans certains cas expliqués plus haut dans cette rubrique dans,. [Impossible de se connecter aux points de terminaison SSM](#systems-manager-ssm-agent-troubleshooting-endpoint-access) `ec2messages.{{region}}.amazonaws.com`
**Note**
L'alternative à l'utilisation d'un point de terminaison de VPC est l'activation de l'accès Internet sortant sur vos instances gérées. Dans ce cas, les instances gérées doivent également autoriser le trafic sortant HTTPS (port 443) vers les points de terminaison suivants :
`ssm.{{region}}.amazonaws.com`
`ssmmessages.{{region}}.amazonaws.com`
`ec2messages.{{region}}.amazonaws.com`
L'SSM Agent initie toutes les connexions au service Systems Manager dans le cloud. Vous n'avez donc pas besoin de configurer votre pare-feu pour autoriser le trafic entrant vers vos instances pour Systems Manager.
Pour de plus amples informations sur ces points de terminaison, consultez [Référence : ec2messages, ssmmessages et autres opérations d'API](systems-manager-setting-up-messageAPIs.md).
Pour résoudre les problèmes avec vos points de terminaison de VPC, procédez comme suit :
+ Assurez-vous que les points de terminaison du VPC sont inclus au niveau du VPC. Si le point de terminaison d’un VPC portant un nom de service spécifique n’est pas trouvé sur le VPC, vérifiez d’abord que la prise en charge de DNS est activée au niveau du VPC. Créez ensuite un nouveau point de terminaison de VPC et associez‑le à un sous-réseau dans chaque zone de disponibilité.
+ Assurez-vous qu'un nom DNS privé est activé au niveau du point de terminaison du VPC. Les noms DNS privés sont activés par défaut, mais ils peuvent avoir été désactivés manuellement à un moment donné.
+ Assurez-vous que les points de terminaison VPC existants sont associés au sous-réseau approprié. En outre, assurez-vous que le VPCE est déjà associé à un sous-réseau de cette zone de disponibilité.
Pour plus d’informations, consultez les rubriques suivantes :
+ [Access an Service AWS using an interface VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) dans le *guide AWS PrivateLink *
+ [Associate a private DNS name](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html#associate-private-dns-name) dans le *guide AWS PrivateLink *
+ [Renforcement de la sécurité des instances EC2 à l’aide des points de terminaison de VPC pour Systems Manager](setup-create-vpc.md)
## Vérifiez les attributs de votre VPC DNS-related
Si vous utilisez un cloud privé virtuel (VPC), dans le cadre de la vérification de la configuration de votre VPC, assurez-vous que les attributs `enableDnsSupport` et `enableDnsHostnames` sont activés.
Vous pouvez activer ces attributs à l'aide de l'action d'[API ](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVpcAttribute.html) ModifyVPCAttribute d'Amazon EC2 ou de la commande modify-vpc-attribute. AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-vpc-attribute.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-vpc-attribute.html)
Pour plus d’informations sur l’activation de ces attributs dans la console Amazon VPC, consultez la section [View and update DNS attributes for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns-updating.html) du *guide de l’utilisateur Amazon VPC*.
**Note**
L'alternative à l'utilisation d'un point de terminaison de VPC est l'activation de l'accès Internet sortant sur vos instances gérées. Dans ce cas, les instances gérées doivent également autoriser le trafic sortant HTTPS (port 443) vers les points de terminaison suivants :
`ssm.{{region}}.amazonaws.com`
`ssmmessages.{{region}}.amazonaws.com`
`ec2messages.{{region}}.amazonaws.com`
L'SSM Agent initie toutes les connexions au service Systems Manager dans le cloud. Vous n'avez donc pas besoin de configurer votre pare-feu pour autoriser le trafic entrant vers vos instances pour Systems Manager.
Pour de plus amples informations sur ces points de terminaison, consultez [Référence : ec2messages, ssmmessages et autres opérations d'API](systems-manager-setting-up-messageAPIs.md).
## Vérification des règles d’entrée sur les groupes de sécurité de point de terminaison
Assurez-vous que tous les points de terminaison VPC que vous avez configurés (`ssm``ssmmessages`, et`ec2messages`) incluent une règle d'entrée sur leurs groupes de sécurité afin d'autoriser le trafic entrant sur le port 443. Si nécessaire, vous pouvez créer un nouveau groupe de sécurité dans le VPC avec une règle d'entrée pour autoriser le trafic sur le port 443 pour le bloc de Inter-Domain routage sans classe (CIDR) du VPC. Après avoir créé le groupe de sécurité, attachez‑le à chaque point de terminaison de VPC.
Pour plus d’informations, consultez les rubriques suivantes :
+ [Comment créer des points de terminaison VPC afin de pouvoir utiliser Systems Manager pour gérer des instances EC2 privées sans accès à Internet ? ](https://repost.aws/knowledge-center/ec2-systems-manager-vpc-endpoints)sur AWS Re:POST
+ [VPC CIDR blocks](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html) dans le *guide de l’utilisateur Amazon VPC*
## Utiliser `ssm-cli` pour résoudre les problèmes de disponibilité des nœuds gérés
À partir de la version 3.1.501.0 de l'SSM Agent, vous pouvez l'utiliser `ssm-cli` pour déterminer si un nœud géré répond aux exigences principales pour être géré par Systems Manager et pour apparaître dans les listes de nœuds gérés dans Fleet Manager. `ssm-cli` est un outil de ligne de commande autonome inclus dans l'installation SSM Agent. Il contient des commandes préconfigurées qui rassemblent les informations requises afin de déterminer pourquoi une instance Amazon EC2 ou une machine non EC2, confirmée comme en cours d'exécution, ne figure pas dans vos listes de nœuds gérées dans Systems Manager. Ces commandes sont exécutées lorsque vous spécifiez l'option `get-diagnostics`.
Pour plus d'informations, consultez [Résolution des problèmes de disponibilité des nœuds gérés à l'aide de `ssm-cli`](troubleshooting-managed-nodes-using-ssm-cli.md).