Surveillance et observabilité : savoir que quelque chose s'est cassé avant le client
Quoi mesurer
Commencez par quatre : taux de requêtes, taux d'erreurs, temps de réponse aux extrêmes et saturation des ressources. Ajoutez une métrique commerciale — commandes par heure, inscriptions, envois — qui capturera des pannes que l'infrastructure ne voit pas.
Le temps de réponse moyen est trompeur. Regardez le 95e et 99e percentile ; c'est là que se trouvent les utilisateurs en colère.
Des journaux utiles
Structurés, avec un identifiant de requête qui accompagne un appel à travers tout le système, et sans information personnelle inutile. Un journal en texte libre est une archive, pas un outil d'investigation.
Des alertes qui n'épuisent pas
Alertez sur des symptômes que l'utilisateur ressent, pas sur chaque anomalie technique. Chaque alerte doit inclure ce qui s'est passé, l'impact et le premier pas. Une alerte sans action — supprimez-la. La fatigue d'alertes est la cause numéro un de rater un vrai incident.
Pour aller plus loin
Ajoutez du traçage distribué montrant le chemin d'une requête entre composants avec des temps. Dans les systèmes divisés, c'est la seule façon de répondre à « pourquoi ça a pris trois secondes » sans deviner, et cela raccourcit les enquêtes d'heures en minutes.