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.

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”

    • En JS : https://www.npmjs.com/package/js-logger

    • En Python : https://docs.python.org/3/howto/logging.html

    • En Php : https://www.loggly.com/ultimate-guide/php-logging-libraries/

• 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).

Imrane 🏖