[Logs] Pourquoi avoir recours à des logs dans une application 1/8

Auteur du billet de blog : Nicolas Hilaire - Neotech Solutions

Nicolas Hilaire

Consultant .NET
  Publié le jeudi 21 avril 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...

Ce billet est le premier d’une petite série sur les logs, visant à réviser et à approfondir le sujet afin de faire en sorte que vos applications aient des bons logs. Bien sûr, cela sera orienté .NET avec le C# comme langage.

Voici le plan prévisionnel des billets

  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

 

Commençons par le début … pourquoi loguer ? Mon application fonctionne pourquoi je rajouterai des logs ?

Je pense que n’importe quel développeur sait qu’il est important de loguer et qu’on s’en rend compte bien souvent trop tard. Typiquement, on a un code en production qui plante et en analysant le code, on se rend bien compte que « non! ce n’est pas possible, ça ne peut pas planter ». Bien souvent, il est difficile de débuggeur avec le code ou l’environnement de production, et combien de fois j’ai pu constater qu’en local on ne reproduit pas le problème, même avec les données de la base de prod … Alors, l’ultime solution est de rajouter du code à l’intérieur de notre application qui va permettre de tracer les endroits où on passe dans le code, les différentes valeurs des paramètres, etc. Bref, comprendre un peu ce qui se passe.

Cela nécessite généralement de redéployer du code en production, mettre à jour une assembly plus ou moins à l’arrache, bref on jongle, on tâtonne, on a des sueurs froides, …

D’où l’idée de mettre en place des logs à des endroits stratégiques dans son code, lorsqu’on traite des exceptions, lorsqu’on arrive à des endroits limites, etc. Un log se caractérise par un petit bout de code qui va permettre de stocker un message pour une consultation ultérieure. Le stockage peut-être fait sur beaucoup de supports différents, fichiers, base de données ou simplement envoyé par mail… Dans la majorité des cas, on utilise des fichiers. Simples, pratiques, et quand il commence à y en avoir beaucoup, il est facile de les supprimer.

On peut loger simplement dans son application en écrivant dans un fichier. Un code simple pour illustrer ça pourrait être :

A noter qu’on utilise une surcharge du constructeur StreamWriter pour ne pas écraser le fichier à chaque fois.

Mais vous vous en doutez, écrire un tel code est un peu idiot. En plus, c’est un code peu robuste, très figé et qui peut même faire planter notre application (accès concurrents au fichier, problème de droits, etc.). Nous aurions tout à fait intérêt à utiliser un outil qui fait déjà tout ça et en mieux.

C’est justement le sujet du prochain billet où je vais vous présenter rapidement un de ces outils les plus connus, à savoir log4Net.

Commentaires