Comment savoir si votre application fonctionne réellement correctement
Vous venez de déployer une nouvelle version. Le pipeline est vert. L'artefact est en production. Et maintenant ?
Quand votre application n'a que quelques utilisateurs, vous pouvez ouvrir un navigateur, cliquer pendant une minute et confirmer que tout fonctionne. Mais dès que votre application sert des dizaines, des centaines ou des milliers de personnes simultanément, cette vérification manuelle ne passe plus à l'échelle. Il y a trop de chemins d'exécution à tester, trop d'utilisateurs qui interagissent avec différentes fonctionnalités, et trop peu de temps pour tout vérifier à la main.
La question centrale est simple : comment savoir si la nouvelle version fonctionne réellement comme prévu après le déploiement ?
Ce que les signaux de santé vous indiquent
Toute application en production produit des signes indiquant si elle est en bonne santé ou non. Considérez-les comme des signes vitaux. Un médecin vérifie le pouls et la température pour évaluer l'état d'un patient. De même, vous avez besoin de signaux qui vous indiquent si votre application est vivante, répond correctement et reste dans des limites acceptables.
Ces signaux sont appelés signaux de santé. Ce sont les points de données qui vous permettent de déterminer si votre application fonctionne normalement après un déploiement, et en continu pendant son exécution.
Voici un moyen rapide de vérifier manuellement deux des signaux de santé les plus courants juste après un déploiement :
# Vérifier si le point de terminaison de santé de l'application répond
curl http://localhost:8080/health
# Sortie attendue (exemple) :
# {"status":"ok","uptime":"2m34s"}
# Rechercher les erreurs récentes dans le journal d'application
grep 'ERROR' /var/log/app.log | tail -20
Les signaux de santé proviennent de plusieurs sources, et chacun sert un objectif différent.
Journaux : l'histoire brute de ce qui s'est passé
Les journaux sont la forme la plus basique de signal de santé. Chaque fois que votre application reçoit une requête, échoue à se connecter à une base de données ou termine le traitement d'un travail, elle peut écrire une ligne décrivant ce qui s'est passé. Les journaux vous fournissent un enregistrement chronologique des événements.
Lorsque les utilisateurs commencent à signaler des erreurs, les journaux sont souvent le premier endroit où vous regardez. Vous ouvrez le fichier journal ou l'outil de recherche, filtrez par la fenêtre temporelle où le problème a commencé, et remontez pour trouver ce qui a mal tourné. Les journaux répondent à la question : « Que s'est-il passé juste avant cette erreur ? »
Mais les journaux ont une limite. Imaginez lire des milliers de lignes de journal par minute juste pour confirmer que tout est normal. Ce n'est pas pratique. Les journaux sont excellents pour le débogage, mais ils ne sont pas efficaces pour une évaluation continue de la santé.
Métriques : des nombres qui montrent des tendances
Les métriques résolvent le problème de volume que créent les journaux. Au lieu de lire des événements individuels, vous collectez des mesures numériques à intervalles réguliers. Les métriques courantes incluent :
- Combien de requêtes arrivent par seconde
- Temps de réponse moyen
- Pourcentage de requêtes qui retournent des erreurs
- Utilisation mémoire
- Utilisation CPU
Avec les métriques, vous voyez des tendances au fil du temps. Si le temps de réponse double soudainement, c'est un signe d'alerte même si aucune erreur ne s'est encore produite. Si l'utilisation mémoire augmente régulièrement sur plusieurs jours, vous pourriez être confronté à une fuite mémoire qui finira par planter l'application.
Les métriques vous permettent de détecter les problèmes avant qu'ils ne deviennent visibles pour les utilisateurs. Elles compressent des milliers d'événements en un seul nombre que vous pouvez suivre et sur lequel vous pouvez alerter.
Surveillance : collecte, affichage et alertes
Les journaux et les métriques doivent être collectés et affichés quelque part où vous pouvez les surveiller en continu. Ce processus s'appelle la surveillance. La surveillance ne consiste pas seulement à collecter des données. Il s'agit de rendre ces données utiles.
Une bonne configuration de surveillance fait trois choses :
- Collecte les journaux et les métriques de votre application et de votre infrastructure
- Affiche les données sur des tableaux de bord pour voir l'état actuel en un coup d'œil
- Alerte lorsque quelque chose sort des limites normales
Par exemple, vous pouvez définir une règle : si plus de cinq pour cent des requêtes échouent dans une fenêtre de cinq minutes, envoyez une notification. Cette alerte peut arriver sous forme de notification téléphonique, d'e-mail ou de message dans votre chat d'équipe. L'objectif est d'être informé des problèmes avant que vos utilisateurs ne vous le disent.
Pourquoi les signaux de santé sont importants tôt
Plus tôt vous détectez un problème, plus vite vous pouvez réagir. Si vous ne réalisez que votre application est cassée après que les utilisateurs ont inondé les réseaux sociaux de plaintes, le problème a déjà duré un certain temps. Dans le contexte du CI/CD, les signaux de santé servent d'étape de vérification après le déploiement. Ils répondent à la question : « Cette version a-t-elle réellement fonctionné en production ? »
Sans signaux de santé, vous déployez à l'aveugle. Vous poussez une nouvelle version, croisez les doigts et attendez que quelqu'un se plaigne. Avec les signaux de santé, vous savez en quelques minutes si la version est stable ou doit être annulée.
Les signaux de santé permettent également de détecter les problèmes qui apparaissent progressivement. Une fuite mémoire peut prendre des heures ou des jours pour causer des problèmes visibles. Une dégradation lente du temps de réponse peut passer inaperçue pour les utilisateurs jusqu'à ce qu'elle franchisse un seuil. La surveillance continue des signaux de santé détecte ces problèmes lents avant qu'ils n'impactent les utilisateurs.
Une liste de contrôle pratique des signaux de santé
Si vous mettez en place des signaux de santé pour la première fois, voici une liste de contrôle minimale pour commencer :
- Choisissez trois métriques pour commencer : le taux de succès des requêtes, le temps de réponse moyen et le nombre d'erreurs. Cela couvre les modes de défaillance les plus courants.
- Définissez une alerte : notifiez votre équipe lorsque le taux d'erreur dépasse cinq pour cent pendant cinq minutes consécutives.
- Vérifiez les journaux après chaque déploiement : même si les métriques semblent bonnes, analysez les journaux pour détecter des erreurs inattendues dans les dix premières minutes suivant une version.
- Ajoutez un point de terminaison de santé : créez une URL simple qui renvoie l'état de l'application. Les outils de surveillance peuvent interroger ce point de terminaison toutes les quelques secondes pour confirmer que l'application est vivante.
Ce n'est pas exhaustif, mais c'est suffisant pour détecter la plupart des problèmes qui surviennent après un déploiement.
L'essentiel à retenir
Les signaux de santé transforment le déploiement d'un processus aveugle en un processus vérifiable. Les journaux vous racontent l'histoire de ce qui s'est passé. Les métriques vous montrent les tendances au fil du temps. La surveillance relie le tout et vous alerte en cas de problème. Commencez par les bases : quelques métriques, une alerte et l'habitude de vérifier après chaque déploiement. Cela suffira à détecter la plupart des problèmes avant vos utilisateurs.