Niveaux de logs et pratique
debug/info/warn/error, structuration et interdits.
Objectifs
À la fin de cette leçon, vous saurez :
- choisir le bon niveau de log ;
- structurer une sortie exploitable ;
- éviter les pièges (logs de secrets, bruit).
🔗 Pour vous rafraîchir la mémoire : migrations de schéma · CRUD en SQL · anatomie d'une requête HTTP
Les quatre niveaux
| Niveau | Quand | Exemple |
|---|---|---|
| debug | diagnostic fin, désactivé en prod | "cache miss sur tasks:12" |
| info | événement normal notable | "Serveur démarré sur :3000" |
| warn | anormal mais traité | "retry 2/3 vers la base" |
| error | échec nécessitant action | "INSERT échoué : contrainte FK" |
Règle de lecture opérationnelle : une prod saine n'émet que info. Tout warn récurrent est un bug en attente ; tout error déclenchera bientôt une alerte (chapitre monitoring). Si vos logs d'erreur sont noyés dans du debug, vous ne verrez rien venir.
Structurer plutôt qu'aligner
logger.log('Serveur démarré', { port, env }); // NestJS Logger
// JSON structuré en prod :
{"level":"info","msg":"tâche créée","taskId":42,"userId":7,"durée_ms":3}
Les champs structurés se filtrent (jq, Loki, CloudWatch) ; les phrases concaténées ne se cherchent qu'au grep. Inclure systématiquement : identifiants (qui/quoi), durée si pertinent, pas plus — chaque champ est un coût de stockage.
Les interdits absolus
❌ logger.debug(process.env) → secrets dans les logs
❌ console.log(motDePasse, token) → idem, même en dev (habitude)
❌ logger.error pour un 404 normal → bruit qui noie les vrais problèmes
❌ logs sans identifiant de requête → impossible de suivre un incident
Le réflexe sécurité : ce qui sort dans un log peut fuiter via une capture d'écran, un partage de fichier ou un agrégateur tiers. Traitez les logs comme des données sensibles.
Corréler avec un request id
[req-7f2a] GET /tasks → 200 (12ms)
[req-7f2a] SQL SELECT * FROM tasks (8ms)
Un identifiant propagé de bout en bout relie toutes les lignes d'un même traitement — c'est la base de la corrélation, étendue au tracing distribué au chapitre observabilité.
Exercice
- Attribuez un niveau : "utilisateur inconnu à la connexion", "migration appliquée", "timeout Redis".
- Nettoyez votre projet : traquez les console.log oubliés.
- Ajoutez un request-id simple (compteur ou uuid par requête) dans votre serveur vanilla.
Résumé
- debug/info/warn/error : quatre niveaux, une discipline.
- Logs structurés + ids corrélés = incidents lisibles.
- Jamais de secrets ni de bruit : le log est une surface sensible.
Correction disponibleCherchez d’abord par vous-même.Voir la correction
Correction
Réponses détaillées
Question 1. warn (échec d'authentification normal mais surveillé — pic = attaque), info (événement d'exploitation), error (dépendance externe perdue, à alerter).