[Logs] Ecrire un message de log utile 3/8

Auteur du billet de blog : Nicolas Hilaire - Neotech Solutions

Nicolas Hilaire

Consultant .NET
  Publié le jeudi 19 mai 2016

Artisan logiciel particulièrement intéressé par les technologies .NET. Polyvalent et curieux, je suis néanmoins à l'écoute des autres technologies du marché. MVP (Microsoft Most Valuable Professional) de 2007 à 2014, je suis également auteur d'un ouvrage pour apprendre le C#, à destination des débutants et de plusieurs MOOCs sur le C#, Windows Phone ou ASP.NET MVC...

Nous avons parlé de logs, de log4Net, voici un petit billet sur ce qu’il faut mettre dans un log pour qu’il soit exploitable.

Pour rappel, voici les différents billets sur le sujet :

  1. Pourquoi avoir recours à des logs dans une application
  2. Utiliser Log4Net dans son application
  3. Ecrire un message de log utile
  4. Les appenders Log4Net
  5. Ecrire son propre appender Log4Net pour loguer dans MongoDB
  6. Centraliser les logs avec GrayLog
  7. Loguer dans GrayLog depuis une application Windows Phone
  8. Centralisation de logs avec ELK

 

Bien sûr, il est important de faire en sorte que le message de log serve à quelque chose et puisse être exploitable par les personnes qui veulent comprendre ce qu’il se passe. N’oubliez pas que sur une application centralisée à fort trafic, il peut y avoir énormément de logs, potentiellement mélangés, il faut donc que le log ne se contente pas d’écrire juste un « je suis passé par là ».

Le plus important à mon avis est le contexte. Si on a une information qui permette de limiter le contexte, alors il faut la mettre. Un identifiant de connexion, un id d’utilisateur, un identifiant de panier, que sais-je… N’oubliez surtout pas de le mettre.

Il faut également donner des informations sur le moment où s’est produit l’événement. Une date complète est indispensable. Fort heureusement, les bibliothèques de log ajoutent ça très facilement, nous avons vu l’exemple avec log4Net.

S’il s’agit d’une erreur, bien sûr le message de l’exception, la ligne où se produit le problème, etc. ; mais on se doit d’aller plus loin, en fournissant notamment les paramètres de la méthode appelée, et bien sûr les valeurs de ces paramètres. Ainsi, il sera plus facile de reproduire le problème unitairement. On peut également fournir la call-stack pour savoir par où on est passé pour en arriver là.

On peut bien sûr ajouter un petit message personnalisé pour indiquer les raisons du log.

Il peut être pertinent de fournir des informations sur le serveur également, nom du serveur s’il y en a plusieurs, mémoire disponible, …

Et vous, voyez-vous d’autres éléments indispensables à fournir dans un message de log ?