AWS CloudWatch + yCrash = Surveillance + RCA

Nous avons eu une panne dans notre application en ligne GCeasy le lundi matin (PST) le 11 octobre 2021. Lorsque les clients ont téléchargé leurs journaux de collecte de déchets pour analyse, l’application renvoyait une erreur HTTP 504. Le code d’état HTTP 504 indique que les transactions expirent. Dans cet article, nous aimerions documenter notre parcours pour identifier la cause première du problème.

Pile d’applications

Voici les principaux composants de la pile technologique de l’application :

• Instance AWS EC2
• AWS Elastic Beanstalk
• Serveur Web Nginx
• Équilibreur de charge élastique AWS
• Java 8
• matou 8
• MySQL (service RDS)
• AWS S3

AWS Cloud Watch – Outil de surveillance

Fig 1 : rapport de veille AWS Cloud.

Nous utilisons AWS CloudWatch comme outil de surveillance. À partir de la figure 1, vous pouvez voir AWS CloudWatch signaler clairement que la consommation du processeur et la connexion à la base de données MYSQL ont commencé à augmenter à partir d’octobre 09 (vendredi). En fait, en octobre 09, nous avons effectué le déploiement du nouveau code dans l’environnement de production. Il était donc clair que le nouveau code était le coupable, provoquant l’instabilité de l’environnement de production.

AWS CloudWatch a clairement indiqué deux choses :

1. Symptôme du problème (c’est-à-dire que le nombre de connexions CPU et DB a augmenté).
2. Délai depuis le début du problème (09 octobre, vendredi).

Cependant, AWS cloud watch n’a pas signalé la ligne de code (c’est-à-dire la cause première) qui provoquait le pic des connexions CPU ou DB.

Fig 2: rapport de synthèse yCrash.

Nous utilisons yCrash comme outil d’analyse des causes profondes. Cet outil capture le journal GC, le vidage des threads, le vidage du tas, netstat, vmstat, iostat, top, l’utilisation du disque, les journaux du noyau et d’autres artefacts au niveau du système de l’application malade, les analyse et génère instantanément des rapports d’analyse des causes profondes. La figure 2 montre la page de résumé du rapport yCrash. Veuillez vous référer à la flèche rouge sur la figure 2, cela indique que « 20 threads sont bloqués en attente d’une réponse du système externe. » Il donne également un lien hypertexte vers le rapport de thread pour examiner les traces de pile de ces 20 threads BLOQUÉS. Cliquer sur le lien hypertexte affiche la trace de la pile de ces 20 threads, comme le montre la figure 3.

Fig 3: rapport de thread yCrash.

Sur la base de la trace de la pile, vous pouvez voir que ces threads effectuaient des appels à la base de données MySQL. Regardez la flèche rouge sur la figure 3. Elle pointe vers ‘com.tier1app.diamondgc.dao.GCReportDAO.selectReportById(GCReportDAO.java:335)‘. C’est la ligne de code qui effectue l’appel de la base de données MySQL. Nous avons recherché le code source de cette ligne. Cette ligne de code effectuait un appel SQL ‘select’ à une table de la base de données MySQL. Cette requête SQL ‘select’ s’est avérée assez inefficace. Cette inefficacité n’a pas été exposée dans les environnements de test inférieurs car nous n’avions qu’une poignée d’enregistrements sur la table. Cependant, en production, cette table comptait plusieurs millions d’enregistrements. Ainsi, la requête SQL « sélectionner » a commencé à mal fonctionner dans l’environnement de production. Il a fallu de 5 à 7 minutes pour terminer. Au cours de cette période, les threads d’application étaient complètement bloqués, de sorte que les demandes des clients ont finalement commencé à expirer avec une erreur HTTP 504.

Il s’est avéré que ce SQL a été ajouté dans la version récente, qui a été mise en ligne vendredi. Étant donné que yCrash a signalé la ligne de code exacte à l’origine de cette dégradation, nous avons commenté ce SQL « sélectionné ». Une fois le nouveau code déployé, les performances de l’application se sont immédiatement rétablies.

Conclusion

Dans notre blog précédent, nous avons tenté d’expliquer la différence entre un outil de surveillance (AWS Cloud watch) et un outil d’analyse des causes profondes (yCrash) en théorie. Dans ce blog, nous avons encore une fois tenté d’expliquer la différence à travers un problème de production réel. Merci de lire cet article.

Vidéo