Les logs, c’est comme les toilettes : tout le monde en a besoin, mais personne ne veut en parler. Pourtant, sans eux, votre application est un bateau sans gouvernail, un avion sans boîte noire, un chat sans vidéos de chats sur YouTube. Bref, c’est la loose.
Parmi les rituels les plus sacrés du développement, il y a le choix des log levels. DEBUG, INFO, WARNING, ERROR : ces quatre cavaliers de l’apocalypse technique sont partout, et pourtant, leur utilisation reste souvent aussi cohérente qu’un menu de fast-food. Pourquoi ces niveaux existent-ils ? Comment les utiliser sans finir noyé sous des gigaoctets de logs inutiles ? Et surtout, pourquoi certains développeurs transforment-ils leurs logs en journal intime ?
Les Log Levels, ou l’Art de Classer ses Problèmes par Gravité
Les niveaux de logs ne sont pas là pour faire joli. Ils servent à hiérarchiser l’information, comme un tri sélectif pour vos erreurs. Voici la répartition officielle, avec une touche de réalisme :
DEBUG: Pour les détails qui n’intéressent que vous (et encore). C’est le niveau « parano » : vous logguez tout, des variables aux états d’âme de votre algorithme. Utile en développement, catastrophique en production si vous oubliez de le désactiver.INFO: Les logs « normaux ». Un utilisateur s’est connecté, un job a démarré, un service a redémarré. Rien de dramatique, mais c’est bon à savoir. Le problème ? Beaucoup de devs en abusent, transformant leurs logs en roman-feuilleton.WARNING: Quelque chose cloche, mais ce n’est pas (encore) la fin du monde. Un timeout, une ressource manquante, un utilisateur qui tente de deviner son mot de passe. À surveiller, mais pas de panique.ERROR: Là, ça pue. Une exception non gérée, une base de données inaccessible, un paiement qui échoue. C’est le niveau « réveillez-moi à 3h du mat’ ».
Le piège ? Beaucoup de développeurs utilisent ERROR pour tout ce qui les dérange, même quand c’est juste un WARNING. Résultat : les alertes perdent leur sens, et les vrais problèmes se noient dans le bruit. C’est comme crier « AU FEU ! » à chaque fois que quelqu’un allume une bougie. À force, plus personne ne réagit.
La Rotation des Logs, ou Comment Éviter l’Apocalypse du Disque Dur
Les logs, c’est comme les cheveux : ça pousse tout le temps, et si on ne fait rien, ça finit par tout envahir. La rotation des logs, c’est la tondeuse à gazon du sysadmin. Sans elle, votre serveur finit par ressembler à un entrepôt de stockage pour logs obsolètes, avec des fichiers nommés app.log.1, app.log.2, app.log.42 (oui, app.log.3 a mystérieusement disparu).
Les outils comme logrotate (Linux) ou les configurations intégrées dans des frameworks comme Winston (Node.js) ou log4j (Java) permettent de :
- Limiter la taille des fichiers (
size 100M). - Archiver les anciens logs (
rotate 7pour garder 7 jours). - Compresser les archives (
compress). - Supprimer les logs trop vieux (
maxage 30).
Voici un exemple de configuration logrotate pour un fichier de logs classique :
/var/log/myapp/*.log {
daily
missingok
rotate 7
compress
delaycompress
notifempty
create 0640 myapp myapp
sharedscripts
postrotate
systemctl reload myapp
endscript
}
Le vrai défi ? Trouver le bon équilibre. Trop de rotation, et vous perdez des logs utiles. Pas assez, et votre disque dur finit en mode « mémoire pleine ». Certains outils comme ELK Stack (Elasticsearch, Logstash, Kibana) ou Grafana Loki permettent de centraliser et d’indexer les logs, mais attention à ne pas tomber dans le piège du « tout-en-un » qui coûte une fortune en ressources.
Pourquoi Certains Devs Transforment Leurs Logs en Roman-Fleuve
Il y a deux types de développeurs : ceux qui logguent trop peu, et ceux qui logguent comme s’ils écrivaient un scénario pour Netflix. Les premiers vous laissent avec des erreurs mystérieuses et des « ça marche chez moi ». Les seconds vous noient sous des logs si détaillés que vous pourriez reconstituer leur journée minute par minute.
Exemple de log inutile :
INFO: User 12345 clicked on button 'Submit' at 2023-10-05 14:23:45.678 DEBUG: Button 'Submit' has CSS class 'btn-primary' DEBUG: Button 'Submit' is located at coordinates (452, 321) DEBUG: User 12345 has 3 items in cart DEBUG: User 12345's session ID is 'abc123xyz'
Personne n’a besoin de savoir que le bouton « Submit » a une classe CSS. À moins que vous ne déboguiez un problème d’affichage très spécifique, ces logs sont du bruit. Pire, ils ralentissent votre application et remplissent vos fichiers de logs avec des informations inutiles.
La règle d’or : un bon log doit répondre à une question précise. « Pourquoi cette erreur est-elle survenue ? », « Quel utilisateur a déclenché cette action ? », « Où le processus a-t-il échoué ? ». Si votre log ne répond pas à une de ces questions, c’est probablement du superflu.
Conclusion : Les Logs, C’est Comme le Sel
Trop peu, et votre application est fade. Trop, et c’est immangeable. Les niveaux de logs et la rotation ne sont pas des détails techniques : ce sont des outils pour garder le contrôle. Utilisez-les avec parcimonie, comme un chef étoilé utilise le sel. Et surtout, n’oubliez pas : un bon log est un log qui vous fait gagner du temps, pas qui vous en fait perdre.
Alors la prochaine fois que vous écrivez un console.log('test') en production, demandez-vous : est-ce que ce log va vraiment m’aider, ou est-ce que je suis juste en train de polluer le fichier ? En fait, dans 90% des cas, c’est la deuxième option :)