Nous gérons quelques sites Web depuis l'infrastructure AWS d'Amazon depuis environ deux ans et il y a environ deux jours, le serveur web a commencé à tomber en panne une ou deux fois par jour avec la seule erreur que je puisse trouver :
HTTP/1.1 503 Service Unavailable: Le serveur en arrière-plan est à pleine capacitéAucune alarme (CPU/Disk IO/DB Conn) n'est déclenchée par CloudWatch. J'ai essayé d'accéder au site via l'IP élastique pour contourner l'ELB et j'ai obtenu ceci :
Requête HTTP envoyée, en attente de réponse... Erreur de lecture (Connexion réinitialisée par le pair) dans les en-têtes. Nouvel essai.Je ne vois rien d'anormal dans les journaux Apache et j'ai vérifié qu'ils étaient correctement rotés. Je n'ai aucun problème pour accéder à la machine quand elle est "en panne" via SSH et en regardant la liste des processus, je vois 151 processus apache2 qui me semblent normaux. Redémarrer Apache résout temporairement le problème. Cette machine fonctionne uniquement comme serveur web derrière un ELB. Toute suggestion serait grandement appréciée.
Utilisation du CPU Moyenne : 7,45 %, Minimum : 0,00 %, Maximum : 25,82 %
Utilisation de la mémoire Moyenne : 11,04 %, Minimum : 8,76 %, Maximum : 13,84 %
Utilisation du Swap Moyenne : N/A, Minimum : N/A, Maximum : N/A
Utilisation de l'espace disque pour /dev/xvda1 monté sur / Moyenne : 62,18 %, Minimum : 53,39 %, Maximum : 65,49 %
Laissez-moi clarifier que je pense que le problème réside dans l'instance EC2 individuelle et non dans l'ELB, mais je ne voulais pas exclure cette possibilité même si je n'ai pas pu joindre l'IP élastique. Je soupçonne que l'ELB renvoie simplement les résultats de l'instance EC2 réelle.
Mise à jour : 2014-08-26 Je devrais avoir fait cette mise à jour plus tôt, mais le "correctif" a été de prendre un instantané de l'instance "défaillante" et de démarrer l'AMI résultant. Elle n'est plus tombée en panne depuis. J'ai examiné le contrôle de l'état lorsque j'avais encore des problèmes et je pouvais accéder à la page de contrôle de l'état (curl http://localhost/page.html) même lorsque j'avais des problèmes de capacité provenant du répartiteur de charge. Je ne suis pas convaincu que cela était dû à un problème de contrôle de l'état, mais comme personne, y compris Amazon, ne peut fournir de meilleure réponse, je le marque comme tel. Merci.
Mise à jour : 2015-05-06 Je voulais revenir ici et dire que je crois fermement qu'une partie du problème était les paramètres du contrôle de l'état. Je ne veux pas exclure la possibilité qu'il y ait un problème avec l'AMI car les choses se sont définitivement améliorées après le lancement de l'AMI de remplacement, mais j'ai découvert que nos contrôles de santé étaient différents pour chaque répartiteur de charge et que celui qui posait le plus de problèmes avait un seuil de non-fonctionnement agressif et un délai de réponse. Notre trafic a tendance à augmenter de manière imprévisible et je pense qu'entre les paramètres de contrôle de santé agressifs et les pics de trafic, c'était la tempête parfaite. En diagnostiquant le problème, je me suis concentré sur le fait que je pouvais atteindre le point de contrôle de l'état à ce moment-là, mais il est possible que le contrôle de l'état ait échoué en raison de la latence et ensuite nous avions un seuil de santé élevé (pour cet ELB particulier), donc il fallait un certain temps pour que l'instance soit de nouveau considérée comme saine.
