La verbosité des logs
Hello,
Aujourd’hui on va parler de la bonne gestion des logs dans les applications
Les logs (ou journaux) sont des informations que les applications/services remontent concernant leur propre fonctionnement.
Ca permet de savoir si tout se passe bien ou à l’inverse si l’application a trouvé des erreurs.
Le but est d’écrire ces informations dans des fichiers “logs” qu’un humain peut lire pour débugger, investiguer.
Les logs sont super importantes car elles servent aussi bien les Dev que les Ops.
Si ce n'est pas déjà fait, tu peux :
Découvrir notre formation sur le DevOps
Lire toutes les éditions précédentes de la newsletter
Au programme :
Une petite expérience
La verbo quoi ?
Une petite expérience pour commencer
Considérons ce script (en JS) qui fait un truc simple.
Une boucle de 100 000 tours qui fait un calcul mathématique simple.
En l’exécutant, on trouve le résultat suivant :
Execution time (hr): 0s 1.578791ms
Un peu plus d’une milliseconde pour faire 100 000 calculs.
Ajoutons le console.log ( qui print le résultat qui vient d’être calculé sur la console)
Execution time (hr): 0s 361.487417ms
On passe à 360 millisecondes. Soit un code qui prend 240 fois plus de temps à s’exécuter (et 100 000 lignes écrites sur ton terminal).
Remplaçons le console.log par l’écriture dans un fichier de log.txt.
Execution time (hr): 1s 965.187ms
Quasiment 2 secondes (2000 millisecondes) : un code 1300 fois plus lent (et un fichier de 100 000 lignes sur ton disque)
Quel rapport avec l’article ?
Le premier script se contente de faire ce qu’on lui demande.
Les 2 autres scripts font ce qu’on leur demande mais on y a ajouté la gestion des log : on écrit des journaux pour savoir ce qu’il se passe.
La conclusion est simple, écrire beaucoup de log, ca plombe les performances, mais grave.
Tout le but est donc de mettre en place une gestion des log juste suffisante en fonction de la situation.
C’est ce qu’on appelle la verbosité.
La verbo quoi ?
La verbosité des logs, c’est le réglage qui permet de dire au script/app/code quelle quantité de logs on souhaite avoir.
Il y a généralement 4 niveaux de verbosité :
Error : on affiche les erreurs que l’on a détectées. C’est souvent une erreur qui altère le bon fonctionnement et déclenche le plantage du truc.
Les Exceptions, try/catch
Des arguments erronés passés en entrée
Des bugs ou des ressources non disponibles
Warning : on affiche des informations/évènements qui ne plantent pas l’app mais qu’ils seraient bien de corriger si l’on veut garder quelque chose de propre.
Du code déprécié
Des versions pas à jour
Info : on affiche des informations simples qui aident à suivre dans les grandes lignes le déroulement du script/app
Date et heure de lancement et arrêt
Passage d’un bloc fonctionnel à un autre
Debug : on affiche des informations très détaillées pour suivre précisément ce qu’il se passe
Contenu de variables
Résultats d’exécution de chaque boucle
Données retournées par les fonctions
Les niveaux sont inclus les uns dans les autres.
C’est à dire si je règle mon app sur le niveau “Debug”, celle-ci affiche tous les niveaux. Si je règle sur “Warning”, celle-ci n’affiche que les Warning et les Erreurs (et ainsi de suite)
Donc ca veut dire que dans mon code, je dois intégrer tous les types de logs. Et c’est à l’exécution du code que je choisis quel niveau est nécessaire.
Généralement :
On est en Debug sur son environnement de Dev et son poste
Ca nous permet de voir ce que l’on code n’est pas trop mauvais
On est en Info sur la Recette
On est en Warning sur la Pré-prod
On est en Erreur sur la Prod
En effet, plus on se rapproche de la prod, moins on veut impacter les perfs
On veut aussi donner moins d’infos sur le fonctionnement de notre app pour des raisons de sécurité (exemple : ne pas afficher les Warning PHP en production)
Pour aller plus loin
Les logs ont un format qui est à peu près le même partout
Date et heure (format timestamp ou avec gestion des timezone)
Niveau de log
Le message associé
Le top est de voir ce qui se fait dans ton environnement pour ne pas réinventer de format
Il existe plein de lib pour t’aider à coder tes logs
Souvent, ces libs portent le nom de “logger” ou “logging”
Il est généralement déconseillé d’afficher les Warning (et parfois même les erreurs) sur la Prod et surtout côté utilisateur (pour des raisons de sécurité)
Les logs ne devraient être accessibles qu’aux personnes autorisées
Conclusion
Il est super important de coder des logs et tout aussi important de régler le bon niveau de verbosité (j’espère que tu pourras réutiliser ce mot dans une conversation à un repas de famille).
Tes cadeaux pour te remercier de partager la newsletter
Pour rappel, si tu recommandes la newsletter à d’autres personnes, voici les récompenses que tu peux gagner :
25 recommandation → On met en avant ton profil dans un article
50 recommandations → Une visio de 20 min de mentoring DevSecOps avec nous
100 recommandations → Une de nos formations aux choix offertes
Il te suffit de cliquer sur le bouton juste en dessous pour obtenir ton lien personnalisé :
Voilà, c’est tout pour aujourd’hui.
On est curieux d’avoir tes retours.
Partage nous tes réactions en répondant à ce mail.
Si tu as aimé cet article, n’oublie pas de mettre un petit like ! Ça nous aide à comprendre quels sujets on dois creuser.
Passe une excellente journée et à la prochaine.