Pourquoi mon instance Linux EC2 est-elle inaccessible et une ou les deux vérifications de son statut échouent-elles ?

Date de la dernière mise à jour : 08/09/2021

Mon instance Linux Amazon Elastic Compute Cloud (Amazon EC2) est inaccessible et une ou les deux vérifications de son statut échouent. Comment résoudre l'échec de la vérification du statut ?

Brève description

Amazon EC2 surveille l'état de chaque instance EC2 via deux vérifications de statut :

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

La vérification du statut du système détecte les problèmes liés à l'hôte sous-jacent sur lequel votre instance s'exécute. Si l'hôte sous-jacent ne répond pas ou est inaccessible en raison de problèmes réseau, matériels ou logiciels, cette vérification de statut échoue.

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

L'échec de la vérification du statut de l'instance indique un problème lié à l'accessibilité de l'instance. Ce problème se produit en raison d'erreurs au niveau du système d'exploitation, telles que les suivantes :

  • Échec du démarrage du système d'exploitation
  • Échec du montage correct des volumes
  • CPU et mémoire épuisés
  • Panique du noyau

Avertissement : Certaines des résolutions suivantes nécessitent un arrêt et un démarrage de l'instance. Avant d'arrêter et de démarrer votre instance, prenez en compte les points suivants :

  • Les données de stockage d'instances sont perdues lorsque vous arrêtez une instance. Les données sont perdues lorsque vous arrêtez l'instance si votre instance est basée sur le stockage d'instances ou dispose de volumes de stockage d'instances contenant des données. Pour plus d'informations, consultez Déterminer le type d'appareil racine de votre instance.
  • L'arrêt de l'instance peut entraîner sa résiliation si celle-ci fait partie d'un groupe Amazon EC2 Auto Scaling. Votre instance peut faire partie d'un groupe AWS Auto Scaling si vous l'avez lancée avec Amazon EMR, AWS CloudFormation ou AWS Elastic Beanstalk. Dans ce cas, la désactivation dépend des paramètres de protection définis pour votre groupe Auto Scaling. Si votre instance fait partie d'un groupe Auto Scaling, supprimez-la temporairement du groupe avant d'exécuter les étapes de résolution.
  • L'arrêt et le démarrage d'une instance renvoie l'adresse IP publique dans le pool d'adresses IP dynamiques AWS. C'est une bonne pratique d'utiliser une adresse IP élastique au lieu d'une adresse IP publique lors du routage du trafic externe vers votre instance. Si vous utilisez Route 53, vous devrez peut-être mettre à jour les enregistrements DNS Route 53 lorsque l'adresse IP publique change.

Pour plus d'informations, consultez Arrêt et démarrage de votre instance – Présentation.

Solution

1.    Déterminez si la vérification de l'état de l'instance ou de la vérification de l'état du système a échoué en affichant les métriques de vérification de l'état.

2.    Si la vérification du statut du système a échoué, consultez la section La vérification du statut du système a échoué pour mon instance. Comment résoudre ce problème ?

Si la vérification de l'état de l'instance a échoué, consultez les journaux système de l'instance pour déterminer la cause de l'échec. En fonction des données trouvées dans les journaux système, utilisez l'une des résolutions suivantes :

Échec du démarrage du système d'exploitation

Échec du montage correct des volumes

Une vérification de l'état d'une instance peut échouer en raison d'un point de montage qui ne peut pas être monté correctement, comme l'illustre l'exemple suivant :

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

CPU et mémoire épuisés

Utilisation élevée du CPU

Si la métrique CPUUtilization est égale à 100 % ou proche de 100 %, l'instance peut ne pas avoir suffisamment de capacité de calcul pour l'exécution du noyau.

Pour les instances T2 ou T3, consultez les métriques relatives aux crédits CPU dans le tableau des métriques CloudWatch afin de déterminer si les crédits CPU sont égaux ou proches de zéro. Si les crédits de CPU sont à zéro, la métrique CPUUtilization affiche un plateau de saturation aux performances de référence de l'instance. Les performances de base peuvent être de 20 %, 40 %, et ainsi de suite, en fonction du type d'instance.

Les métriques CloudWatch indiquant une utilisation du CPU égale ou proche de 100 %, ou sur un plateau de saturation pour les instancesT2 ou T3, indiquent que la vérification du statut a échoué en raison d'une sur-utilisation des ressources de l'instance. Pour connaître la procédure permettant de résoudre ce problème, consultez la section La vérification du statut de mon instance EC2 Linux a échoué en raison d'une sur-utilisation de ses ressources. Comment résoudre ce problème ?

Les erreurs de périphérique de stockage en mode bloc, les bogues logiciels ou les paniques du noyau peuvent entraîner un pic d'utilisation inhabituel du CPU. Si la métrique CPUUtilization est à 100 % et que les journaux système contiennent des erreurs liées à des périphériques de stockage en mode bloc, des problèmes de mémoire ou d'autres erreurs système inhabituelles, redémarrez l'instance, ou arrêtez-la et démarrez-la.

Mémoire insuffisante

Une forte sollicitation de la mémoire peut entraîner l'échec de la vérification de l'état de l'instance. Dans l'exemple suivant, la mémoire du système d'exploitation est insuffisante et le système arrête 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

Les métriques de mémoire et de disque EC2 ne sont pas envoyées à CloudWatch par défaut. Toutefois, vous pouvez envoyer des métriques supplémentaires à CloudWatch à des fins de surveillance à l'aide de l'agent CloudWatch.

Pour dépanner et résoudre le problème de mémoire insuffisante, envisagez de mettre à niveau l'instance vers un type d'instance plus grand. Vous pouvez également ajouter du stockage d'échange à l'instance pour réduire la sollicitation de la mémoire. Pour plus d'informations, consultez ce qui suit :

Erreurs de disque plein

Si les journaux système contiennent des erreurs de disque plein, l'instance peut être entrée en mode d'urgence, car le périphérique racine est plein.

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

$: /etc/init.d/mysql restart
[....] Restarting mysql (via systemctl): mysql.serviceError: No space left on device
        
        
root@example:~# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.7G  7.7G     0 100% /

Panique du noyau

Une erreur de panique du noyau se produit lorsque le noyau détecte une erreur interne irrécupérable pendant le fonctionnement. Si l'erreur se produit pendant le démarrage du système d'exploitation, il se peut que le noyau ne puisse pas se charger correctement. Cela peut entraîner un échec du démarrage du système d'exploitation. Voici un exemple de message 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)