Comment résoudre les échecs de vérification d'état de mon instance EC2 Linux ?

Brève description

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

• Les contrôles de l'état du système qui détectent les problèmes liés au matériel sous-jacent d'une instance.
• Les surveillances de l'état de l'instance qui vérifient si l'instance est accessible.
  Remarque : les échecs de surveillance de l'état de l'instance se produisent en cas de problèmes liés au système d'exploitation (OS).
• Les vérifications d'état d'Amazon Elastic Block Store (Amazon EBS) attachés qui contrôlent si les volumes Amazon EBS de l'instance sont accessibles et peuvent effectuer des opérations d'E/S.

Résolution

Pour identifier la vérification d'état qui a échoué, consultez les métriques de surveillance de l'état de l'instance.

Pour résoudre les problèmes liés au contrôle de l'état du système ou aux échecs de vérification d’état d'EBS attachés, consultez Comment résoudre les échecs de vérification d'état de mon instance Amazon EC2 ?

Si la surveillance de l'état de l'instance a échoué, consultez les journaux système de l'instance pour connaître la cause de l'échec. Prenez ensuite les mesures suivantes en fonction du problème rencontré.

Important : certaines des résolutions suivantes vous obligent à arrêter puis à démarrer l'instance.

Configurer votre instance pour un arrêt et un démarrage

Remarque : lorsque vous arrêtez et démarrez une instance, son adresse IP publique change. Une bonne pratique consiste à utiliser une adresse IP Elastic pour acheminer le trafic externe vers votre instance au lieu d'une adresse IP publique. Si vous utilisez Amazon Route 53, vous devrez peut-être mettre à jour les enregistrements DNS Route 53 lorsque l'adresse IP publique change. Un arrêt et un démarrage sont différents d'un redémarrage d'instance. Pour plus d'informations, consultez la section Fonctionnement de l'arrêt et du démarrage d'une instance EC2.

Avant d'arrêter et de démarrer votre instance, effectuez les actions suivantes :

• Si votre instance utilise un stockage d'instances, enregistrez les données de volume de stockage d'instances dans un stockage persistant. Par exemple, vous pouvez enregistrer les données dans des volumes Amazon EBS ou des compartiments Amazon Simple Storage Service (Amazon S3).
  Important : Amazon EC2 supprime les données du stockage d'instances lorsque vous arrêtez l'instance.
• Créez un instantané de votre volume EBS. Si vous rencontrez des problèmes, vous pouvez utiliser l'instantané pour restaurer votre instance.
• Supprimez temporairement l'instance de son groupe Amazon EC2 Auto Scaling afin de ne pas résilier accidentellement l'instance lorsque vous l'arrêtez.
  Remarque : EC2 Auto Scaling peut résilier les instances arrêtées dans un groupe Auto Scaling en fonction de vos paramètres de protection de la mise à l'échelle horizontale descendante. Les instances que vous lancez avec Amazon EMR, AWS CloudFormation ou AWS Elastic Beanstalk peuvent faire partie d'un groupe Auto Scaling.
• Définissez le comportement d'arrêt de l'instance sur Stop (Arrêter) pour vous assurer que les instances ne se résilient pas lorsque vous les arrêtez.

Résoudre les problèmes liés à un système d'exploitation qui ne démarre pas

Si les journaux système contiennent des erreurs de démarrage, cela signifie qu'il existe des problèmes de système d'exploitation. Pour résoudre ce problème, consultez la section Comment puis-je résoudre le problème d'échec de l'instance EC2 Linux lors de la surveillance de l'état de l'instance en raison de problèmes liés au système d'exploitation ?

Résoudre les problèmes liés aux volumes EBS qui ne se sont pas montés correctement

Si une défaillance du point de montage a entraîné l'échec de la surveillance de l'état de l'instance, vous recevez une sortie similaire à l'exemple suivant :

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

Pour résoudre cette erreur, consultez ** Résoudre les erreurs « Failed to mount » ou « Dependency failed »** dans la section Comment puis-je résoudre le problème d'échec de l'instance EC2 Linux lors de la surveillance de l'état de l'instance en raison de problèmes liés au système d'exploitation ? Consultez également la section Erreurs d'échec de dépendance dans la section Pourquoi mon instance EC2 Linux passe-t-elle en mode d'urgence lorsque j'essaie de la démarrer ?

Si vous passez d'un type d'instance basé sur Xen à une instance basée sur AWS Nitro System, le montage des volumes risque d'échouer. Les instances Nitro exposent les volumes EBS en tant que périphériques de stockage en mode bloc NVMe, tels que /dev/nvme0n1 ou /dev/nvme1n1. Les noms de périphériques que vous spécifiez dans un mappage de périphérique de stockage en mode bloc sont automatiquement renommés au format /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.

Pour éviter les échecs de montage, utilisez l'étiquette du système de fichiers ou l'UUID du volume dans /etc/fstab au lieu des noms de périphériques du volume. Pour les étapes de configuration, consultez Rendre un volume Amazon EBS disponible pour utilisation.

Résoudre les problèmes liés à un processeur et à une mémoire élevés

Utilisation élevée du processeur

Si la métrique CPUUtilization dans Amazon CloudWatch 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 également les métriques de crédit du processeur. Si les crédits du processeur sont nuls, **CPUUtilization ** s'arrête au niveau de performance de base pour le type d'instance. Par exemple, si les performances de base sont de 20 % ou 40 %, l'instance ne dépasse pas ce niveau d'utilisation du processeur.

Pour résoudre les problèmes d'utilisation élevée du processeur, consultez Comment résoudre les problèmes d'utilisation élevée du processeur sur une instance Amazon EC2 Linux ?

Mémoire élevée

Si la pression de votre mémoire est élevée, le message d'erreur suivant s'affiche dans les journaux :

"[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"

Pour résoudre cette erreur, arrêtez le processus qui consomme le plus de mémoire. Si vous avez besoin de tous les processus en cours d'exécution, mettez à niveau l'instance vers un type d'instance plus important. Vous pouvez également ajouter du stockage d'échange à l'instance ou partitionner votre disque dur pour réduire la pression sur la mémoire.

Pour plus d'étapes de dépannage, consultez Comment résoudre les problèmes d'utilisation élevée de la mémoire sur mon instance EC2 Linux ?

Résoudre les problèmes liés à un disque plein

Si le périphérique racine est plein, l'instance passe en mode d'urgence et vous recevez une sortie de journal système similaire à l'exemple suivant :

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

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

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

Pour résoudre ce problème, augmentez la taille de votre volume. Vous pouvez aussi consulter la section Résoudre l'erreur « No space left on device » de la rubrique Comment résoudre les problèmes liés à une instance EC2 Linux dont la vérification d'état échoue en raison d'une utilisation excessive des ressources ?

Résoudre des erreurs de panique du noyau

La panique du noyau se produit si le noyau détecte une erreur interne pendant l'opération. Si le noyau ne se charge pas, l'instance ne peut pas démarrer et vous recevez une sortie de journal système similaire à l'exemple suivant :

Linux version2.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 résoudre ce problème, consultez la section Comment résoudre l'erreur « Kernel panic - not sync » dans mon instance EC2 ? Ou revenez à un noyau stable connu.

Résoudre les problèmes de réseau

Pour identifier et résoudre les pannes réseau, consultez Comment résoudre les problèmes de configuration réseau au niveau du système d'exploitation sur mon instance Amazon EC2 Linux ?

Résoudre les problèmes liés aux performances limitées des volumes EBS racines

Si le volume EBS dépasse ses limites d'opérations d'entrée/sortie par seconde (IOPS) ou de débit, Amazon EC2 limite le volume. Par conséquent, l'instance échoue à ses surveillances de l'état et ne répond plus.

Surveillez et analysez les métriques CloudWatch pour Amazon EBS afin de comprendre les IOPS ou le débit attendus du volume.

Remarque : pour identifier un volume limité, vérifiez si les métriques d'IOPS ou de débit restent les mêmes au fil du temps. Pour plus d'informations, consultez la section Surveiller les caractéristiques d'I/O à l'aide de CloudWatch.

Pour résoudre temporairement le problème, redémarrez ou arrêtez et démarrez votre instance pour mettre fin aux processus qui utilisent les IOPS et le débit. Pour une solution à long terme, optez pour un type et une taille de volume EBS plus adaptés à votre charge de travail.

Informations connexes

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

Comment résoudre les échecs de vérification d'état de mon instance Amazon EC2 Windows ?