Vous decouvrez la qualite de votre observabilite au pire moment possible : quand quelque chose est casse, que les clients le remarquent, et que vous ne savez pas pourquoi. Tout ce que je fais ici vise ce moment. Le but est de repondre a « que se passe-t-il et pourquoi » en minutes, pas en heures. Une bonne observabilite, c’est la difference entre un incident calme et un incident frenetique.
Journalisez des donnees structurees, pas des phrases
Les lignes de log lisibles par l’humain semblent sympathiques jusqu’a ce que vous deviez en chercher dix millions. Alors vous ecrivez des regex fragiles contre de la prose. Je journalise des enregistrements structures, cle-valeur ou JSON, pour que les logs soient interrogeables comme une base plutot que fouilles comme un journal intime.
// Pas ca :
log.info("Utilisateur " + userId + " echec connexion depuis " + ip)
// Ca :
log.info("login_failed", {
user_id: userId,
ip: ip,
reason: "bad_password",
attempt: 3
})Maintenant « montre-moi toutes les connexions echouees de cet utilisateur dans la derniere heure » est un filtre, pas un projet d’archeologie. Choisissez des noms de champ coherents entre services pour que le meme concept ait la meme cle partout, et une requete ecrite une fois fonctionne sur tout le systeme.
Utilisez les niveaux avec discipline
Les niveaux de log n’aident que s’ils veulent dire quelque chose de coherent. Quand tout est journalise en INFO, le niveau n’est que du bruit. Ma regle empirique :
- ERROR, c’est quelque chose de casse qu’un humain doit regarder. Si ca ne merite pas d’attention, ce n’est pas une erreur.
- WARN, c’est inattendu mais gere, le genre de chose qu’il vaut la peine de surveiller pour un motif.
- INFO, ce sont des evenements metier importants : une commande passee, un travail termine.
- DEBUG, c’est du detail pour le developpement local, en general coupe en production.
Le test pour ERROR est simple : si une alerte se declenchait pour chacun, seriez-vous en colere ? Si oui, ce n’est pas vraiment une erreur, et vous venez de vous entrainer a ignorer le niveau cense vous reveiller.
Faites circuler un identifiant de requete partout
Dans tout systeme a plus d’un service, une seule action utilisateur devient une douzaine de lignes de log eparpillees sur plusieurs machines. Sans un fil qui les relie, vous devinez. Je genere un identifiant de correlation a la frontiere et le passe a chaque appel en aval et dans chaque ligne de log. Alors un seul identifiant reconstitue tout le chemin d’une requete, pour la meme raison qui me pousse a garder des formes d’erreur coherentes dans le guide de conception d’API REST : quand autre chose doit suivre la piste, la structure gagne.
Mesurez les trois choses qui parlent de sante
Les logs parlent d’evenements precis. Les metriques parlent du systeme dans son ensemble, et ce sont elles qui font tourner vos tableaux de bord et vos alertes. Pour tout service qui traite des requetes, je suis le debit, les erreurs et la duree : combien de requetes, combien ont echoue, et combien de temps elles ont pris. Regarder la distribution de latence plutot que la moyenne compte, car la moyenne cache la queue lente ou les vrais utilisateurs souffrent.
- Suivez la latence au 95e et au 99e percentile, pas seulement la moyenne.
- Suivez le taux d’erreur en pourcentage pour qu’il ait du sens a tout niveau de trafic.
- Suivez la saturation, le taux de remplissage de vos ressources, pour voir les ennuis avant qu’ils deviennent une panne.
Alertez sur les symptomes, pas sur les causes
Une alerte devrait signifier qu’un humain doit agir maintenant. Sinon, ce devrait etre un tableau de bord, pas une alerte. La facon la plus rapide de faire detester l’astreinte, ce sont des alertes qui se declenchent sans cesse et ne veulent rien dire, car les gens apprennent a les balayer puis ratent celle qui comptait. J’alerte sur les symptomes vus par l’utilisateur, comme un taux d’erreur qui franchit un seuil ou une latence qui explose son budget, plutot que sur des causes internes comme un CPU eleve, qui peut etre parfaitement normal.
Une derniere chose qui paie : ne journalisez jamais de secrets, mots de passe, jetons ou details de paiement complets. Il est facile de les laisser fuiter dans les logs par accident, et les logs s’etalent sur des systemes aux controles d’acces plus faibles que votre base. Le meme soin guide par les contraintes que j’ai decrit dans les bonnes pratiques de schema de base de donnees vaut ici aussi. Decidez ce qui est sensible, puis assurez-vous que ca n’atteigne jamais une ligne de log.