Comment résoudre les problèmes liés à la vérification de l'état de mon instance Linux EC2 ?

Brève description

Amazon EC2 utilise trois vérifications d'état pour surveiller l'état des instances EC2.

Vérification de l’état du système

La vérification de l'état du système détecte les problèmes liés au matériel sous-jacent d'une instance. Si le matériel sous-jacent ne répond pas ou est inaccessible en raison de problèmes réseau, matériels ou logiciels, la vérification de l'état du système échoue.

Vérification de l’état de l'instance

La vérification de l'état de l'instance échoue lorsque vous ne pouvez pas accéder à l'instance. Les vérifications de l'état de l’instance peuvent échouer pour les raisons suivantes :

• Le système d'exploitation (OS) ne démarre pas
• Les volumes Amazon Elastic Block Store (Amazon EBS) ne parviennent pas à être montés correctement
• Le processeur et la mémoire sont épuisés
• Panique du noyau
• Défaillance du réseau
• Limitation des paramètres du volume EBS racine

Vérifications de l’état d’EBS attaché

Les vérifications de l’état d’EBS attaché consistent à vérifier si les volumes EBS attachés à une instance sont accessibles et s’ils peuvent réaliser des opérations d'I/O. Pour plus d'informations, consultez la section ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html#attached-ebs-status-checks)Vérifications de l’état d’EBS attaché[.

Résolution

Pour déterminer si la vérification de l'état de l'instance ou du système a échoué, consultez les métriques de vérification de l’état de l’instance.

Si la vérification de l'état du système a échoué, consultez la section Pourquoi mon instance Linux EC2 a-t-elle échoué à la vérification de l'état du système ?

Si la vérification de l'état de l'instance a échoué, consultez les journaux système de l'instance pour connaître la cause de l'échec. Puis, choisissez l'une des options de résolution suivantes pour résoudre le problème.

Important : Certaines des résolutions suivantes vous obligent à arrêter puis à démarrer une instance. Les données d'un volume de stockage d'instances sont perdues lorsque vous arrêtez l'instance. Si votre instance ne contient pas de volumes sauvegardés par EBS, sauvegardez vos données avant de l'arrêter. En outre, l'adresse IPv4 publique de votre instance peut changer une fois que vous l'avez arrêtée et démarrée. Pour retenir la même adresse IPv4 publique, utilisez une adresse IP Elastic. Pour en savoir plus, consultez la section Arrêter et démarrer des instances Amazon EC2.

Le système d'exploitation ne démarre pas

Si les journaux du système contiennent des erreurs de démarrage, consultez la section Comment résoudre les problèmes liés à une instance Linux EC2 dont la vérification de l'état de l'instance a échoué en raison de problèmes liés au système d'exploitation ?

Les volumes EBS ne peuvent pas être montés correctement

Une défaillance du point de montage peut entraîner l'échec de la vérification de l'état de l'instance.

Exemple de sortie de défaillance du point de montage :

[FAILED] Failed to mount /
See 'systemctl status mnt-nvme0n1p1.mount' for details.
[DEPEND] Dependency failed for Local File Systems.

Pour plus d’informations sur ces erreurs, consultez la section Pourquoi mon instance Linux EC2 passe-t-elle en mode d’urgence lorsque j’essaie de la démarrer ? Consultez également la section Comment puis-je résoudre les problèmes liés à une instance Linux EC2 dont la vérification de l’état a échoué en raison de problèmes liés au système d'exploitation ?

Lorsque vous changez le type d'instance d'une instance Xen à une instance basée sur Nitro, le montage du volume peut échouer. Un échec de montage se produit parce que les volumes EBS sont exposés en tant que périphériques de stockage en mode bloc NVMe sur des instances basées sur Nitro. Par exemple, les noms des périphériques sont /dev/nvme0n1 et /dev/nvme1n1. Les noms de périphériques que vous spécifiez dans un mappage de périphériques de stockage en mode bloc sont renommés en noms de périphériques NVMe. Par exemple, /dev/nvme[0-26]n1.

Remarque : Le pilote de périphérique de stockage en mode bloc peut attribuer les noms des périphériques NVMe dans un ordre différent de celui que vous spécifiez dans le mappage de périphérique de stockage en mode bloc. Pour éviter l'échec de montage sur les instances basées sur Nitro, il est recommandé d'utiliser une étiquette ou un UUID pour les noms de périphériques. Pour plus d'informations, consultez la section Rendre un volume Amazon EBS accessible à l’utilisation.

Le processeur et la mémoire sont épuisés

Taux d'utilisation élevé du processeur

Si la métrique CPUUtilization est égale à ou proche de 100 %, l’instance ne dispose pas d’une capacité de calcul suffisante pour exécuter le noyau.

Pour les instances T2 ou T3, vérifiez les métriques de crédit du processeur Amazon CloudWatch pour déterminer si les crédits CPU sont égaux ou proches de zéro. Si les crédits CPU sont nuls, la métrique CPUUtilization indique un plateau de saturation par rapport aux performances de base de l'instance. Par exemple, la performance de base peut être de 20 % ou 40 %. Si l'utilisation du processeur est égale ou proche de 100 %, ou si les instances T2 ou T3 ont atteint un plateau de saturation, la vérification de l'état indique un échec en raison d'une surutilisation des ressources.

Pour résoudre ce problème, consultez la section Comment puis-je résoudre les problèmes liés à une instance Linux EC2 dont la vérification de l’état échoue en raison d'une surutilisation des ressources ?

Les erreurs de périphériques de stockage en mode bloc, les bogues logiciels ou la panique du noyau peuvent provoquer une augmentation inhabituelle de l'utilisation du processeur. Si le taux d'utilisation du processeur est de 100 %, consultez les journaux du système pour détecter toute erreur de périphérique de stockage en mode bloc ou de mémoire ou pour toute autre erreur système inhabituelle. Puis, redémarrez ou arrêtez et démarrez l'instance.

Mémoire insuffisante

Une charge de mémoire élevée peut entraîner l'échec de vérification de l'état de l'instance. Dans l'exemple d'extrait de journal suivant, la mémoire du système d'exploitation est insuffisante et la mise à mort sur mémoire saturée démarre. Pour résoudre cette erreur, arrêtez le processus qui consomme le plus de mémoire.

[115879.769795] Out of memory: kill process 20273 (httpd) score 1285879 or a child
[115879.769795] Killed process 1917 (php-cgi) vsz:467184kB, anon-rss:101196kB, file-rss:204kB

Par défaut, les métriques de mémoire et de disque de l'instance EC2 ne sont pas envoyées à CloudWatch. Pour plus d'informations, consultez la section Collecter des métriques, des journaux et des traces avec l'agent CloudWatch.

Pour résoudre le problème de mémoire insuffisante, mettez à niveau l'instance vers un type d'instance de plus grande taille. Vous pouvez également ajouter du stockage de swap à l'instance pour réduire la charge de mémoire. Pour plus d’informations, consultez la section Comment puis-je allouer de la mémoire en tant que fichier d’échange dans une instance Amazon EC2 ? Consultez également la section Comment puis-je allouer de la mémoire sur une partition de mon disque dur pour qu'elle fonctionne comme un espace d'échange sur une instance Amazon EC2 ?

Erreurs de saturation du disque

Si les journaux système contiennent des erreurs de saturation du disque, cela signifie que l'instance est en mode d'urgence car le périphérique racine est saturé.

Exemple de journal système :

$: sudo service apache2 restart
Error: No space left on device

$: sudo /etc/init.d/mysql restart
[....] Restarting mysql (via systemctl):
mysql.serviceError: No space left on device

$: df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.7G  7.7G     0 100% /

Pour plus d’informations, consultez la section Comment résoudre les problèmes liés à une instance Linux EC2 dont la vérification de l’état échoue en raison d'une surutilisation des ressources ? Consultez également la section Comment puis-je augmenter la taille de mon volume EBS si je reçois un message d'erreur indiquant qu'il n'y a plus d'espace libre sur mon système de fichiers ?

Panique du noyau

La panique du noyau se produit lorsque le noyau détecte une erreur fatale interne en cours de fonctionnement. Si le noyau ne se charge pas correctement, l'erreur se produit pendant le démarrage du système d'exploitation. Un échec de chargement du noyau entraîne l'échec de démarrage d'une instance.

Exemple de sortie d'erreur de panique du noyau :

Linux version
2.6.16-xenU (builder@xenbat.amazonsa) (gcc version 4.0.1 20050727 (Red Hat4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007
Kernel command
line:  root=/dev/sda1 ro 4
Registering block device major 8
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

Pour plus d’informations, consultez la section Comment résoudre l'erreur « Kernel panic - not syncing » dans mon instance EC2 ? Consultez également la section Comment revenir à un noyau stable connu après qu'une mise à jour ait bloqué le redémarrage de mon instance EC2 ?

Défaillance du réseau

Votre réseau peut tomber en panne pour les raisons suivantes :

• Le package cloud-init n'est pas installé sur l'instance
• Le package cloud-init est utilisé pour mettre à jour les configurations réseau au lancement.

Pour corriger cette erreur et installer le package cloud-init sur votre instance, exécutez les commandes suivantes dans votre terminal .

Système d'exploitation Amazon, Amazon Linux 2, Amazon Linux 2023 ou RedHat :

sudo yum install cloud-init -y

Système d'exploitation Ubuntu ou Debian :

sudo apt install cloud-init -y

L'adresse MAC est codée en dur dans un fichier de configuration

Les adresses MAC codées en dur se trouvent dans les fichiers de configuration Linux et dans les fichiers de configuration udev. Les fichiers suivants se trouvent aux emplacements suivants :

• /etc/udev/rules.d/
• /etc/udev/rules.d/70-persistent-net.rules
• /etc/udev/rules.d/80-net-name-slot.rules

Pour résoudre les problèmes réseau qui sont causés par une adresse MAC codée en dur, supprimez les entrées ou les fichiers de configuration, puis exécutez la commande suivante :

sudo mv /etc/udev/rules.d/70-persistent-net.rules /root/

Après avoir déplacé le fichier de configuration, redémarrez le service réseau pour vous assurer de recevoir une nouvelle adresse MAC.

L'adresse IP est codée en dur dans un fichier de configuration du réseau

Lorsque vous créez une Amazon Machine Image (AMI) à partir d'une instance avec une adresse IP configurée de manière statique, le fichier de configuration contient une adresse IP codée en dur.  Pour corriger cette erreur, configurez votre interface réseau pour qu'elle utilise le protocole DHCP.

Remarque : Vous ne pouvez pas mettre à jour les AMI qui existent déjà. Vous devez configurer l'interface réseau pour qu'elle utilise le protocole DHCP avant de créer une nouvelle AMI.

Des pilotes réseau ENA ou Intel améliorés sont manquants

Pour plus d'informations sur les adaptateurs réseau élastique (ENA) ou les pilotes réseau améliorés Intel manquants, consultez la section Mise en réseau améliorée sur les instances Amazon EC2.

**L'interface réseau est automatiquement renommée au démarrage **

Pour désactiver le changement de nom prévisible de l'interface réseau, ajoutez net.ifnames=0 à la ligne de commande du noyau. Pour utiliser l'espace réservé, vous devez activer la mise en réseau améliorée avec l'ENA et recréer ou mettre à jour le fichier de configuration grub.

Limitation des paramètres du volume EBS racine

Lorsque les paramètres du volume EBS racine sont limités, l'instance peut échouer aux vérifications de l’état car elle devient inaccessible et ne répond plus.

La limitation peut se produire lorsque les opérations d'I/O par seconde (IOPS) ou le débit d'un volume EBS dépassent les limites déjà provisionnées. L'instance risque de ne plus répondre ou d'être inaccessible en raison de la dégradation des performances due à la limitation du volume EBS.

Pour résoudre les problèmes de limitation du volume EBS, procédez comme suit :

1. Surveillez et analysez les métriques CloudWatch telles que la longueur de la file d'attente de volumes, les opérations de lecture/écriture du volume et les octets de lecture/écriture du volume. Pour plus d’informations, consultez la section Comment puis-je utiliser les métriques CloudWatch pour calculer le débit moyen et le nombre moyen d'IOPS fournis par mon volume EBS ?
2. Arrêtez et démarrez l'instance, ou redémarrez-la pour résoudre temporairement le problème.
3. Provisionnez des IOPS ou un débit supplémentaire pour le volume EBS. Vous pouvez également opter pour un type et une taille de volume EBS mieux adaptés à votre charge de travail. Pour plus d'informations, consultez la section Demander des modifications du volume Amazon EBS.

Informations connexes

Résoudre les problèmes liés aux instances Amazon EC2 Linux dont les vérifications de l’état ont échoué

Pourquoi mon instance Windows EC2 ne fonctionne-t-elle pas en raison d'un échec de la vérification de l'état du système ou d'une vérification d'état 0/2 ?

Pourquoi mon instance Windows EC2 est-elle en panne en raison d'un échec de la vérification de l'état de l'instance ?

Types de vérifications d'état