#Web2Day 2017 : Logging-driven Development – Logs are not just logs

Quel développeur ne s’est jamais arraché les cheveux à analyser d’énormes fichiers de logs à grands coups de commandes grep ? À peu près aucun.
A travers un quickie de 20 minutes au Web2Day, Pierre Guceski de Logmatic.io nous a partagé son expérience sur les logs, ce que l’on peut en faire et comment y parvenir.

Pour sa présentation, Pierre a choisi de comparer les logs à une agence de presse. En effet, les logs sont dans un fichier, que l’on appelle par ailleurs un journal. Elles caractérisent toute une suite d'événements datés qui racontent l’histoire d'une infrastructure. Que se passe-t-il ? A un instant t, le système a planté, à un autre tout fonctionne correctement, à un autre une connexion a été établie, etc. Tous sont des événements. Par conséquent, si on traite les logs non plus comme des chaînes de caractères mais comme des événements rapportés par l’infrastructure, que peut-on en faire ?

Premiers constats :

  • Peu de gens considèrent les logs comme une suite d'événements rapportée par l'infrastructure.
  • Souvent chacun les gère à sa manière.
  • Chaque événement n'a pas la même importance pour tout le monde.
  • Il y a des problèmes de communication. Par exemple : certains appellent telle donnée un user id, d’autre un client id.
  • Au final on a plusieurs outils incapables de communiquer entre eux

 

Exemple classique d'une analyse de logs

Un utilisateur navigue sur une application web. Soudain, une erreur 500 se produit. Pour déterminer la cause du problème et le corriger, un développeur ouvre le fichier de logs et finit par trouver une stack trace. Il se pose des questions sur la gravité, se dit que ça n'a pas l'air grave car c'est loggué avec la sévérité debug. Mais que ça l'est peut-être finalement étant donné qu'il est en présence d'une exception. Du coup, il se demande ce qui a planté. Il semble que ce soit la base de données mais pourquoi ? Plein de questions dont il n’a pas forcément la réponse avec cette log. D’ailleurs, il n’est même pas certain que cette exception soit la source du problème. Il l'a seulement supposé parce que ça a l'air de correspondre temporellement. Il manque clairement des informations sur le contexte de levée de l'erreur.

Partant de ce constat, Pierre nous propose une façon de travailler, de réfléchir pour faire en sorte qu'à chaque fois que l’on écrit une log, on ait une méthode pour savoir comment s'y prendre et surtout faire en sorte qu’on applique, aujourd’hui comme demain,  les mêmes méthodes afin de garder une cohérence.

 

Choix des sévérités

Tout d’abord, il explique qu'il y a souvent un manque de rigueur dans le choix de la sévérité des logs. Par exemple, tout est en error ou tout en warning... C'est pourquoi, avant de commencer à logguer, il est crucial de choisir un point de vue : soit le point de vue du développeur, soit celui du client. Par exemple, ce qui est une erreur pour les développeurs n’est pas forcément grave pour le client. Par contre, si c’est grave pour le client, il y a de fortes chances que ça le soit aussi pour les développeurs. Bien choisir les sévérités est donc déjà important. S’il n’y a que des logs en error, on risque d'être perdu et s’il n’y en n'a pas assez, on ne va même pas savoir quel est le problème.

 

Les 5 W

Retour sur l’exemple journalistique. Que fait une agence de presse quand elle reçoit une information ? Elle applique la règle des 5 W : when, where, who, what et why.

Ces 5 W sont les questions à se poser à chaque fois que l’on écrit une log.

  • When : le timestamp, fourni par défaut par les librairies de logging.
  • Where : la machine à l'origine de la log.
  • Who : l’acteur qui a généré la log : cela peut être l’application, la classe java, la méthode…
  • What : dans quel contexte ? Par exemple, quel topic Kafka ? Quelle requête à la BDD ? Toutes les questions qui serviront à contextualiser le why.
  • Why : le message de la log pour expliquer pourquoi on a cet événement. Exemple : un client a cliqué sur un bouton, un accès à la base de données qui a planté…

Grâce à ces 5 W, on est capable de construire la log. Mais du coup, une deuxième question se pose car pour spécifier un bon what et un bon why, on a besoin de ces 3 notions : la structure, le standard et la normalisation.

 

Structure, standard et normalisation

La structure

La structure peut être du JSON, c'est même souvent le cas. Plutôt que d’écrire les logs sous forme de caractères, on extrait les éléments qui permettent de construire le contexte afin que ce soit plus lisible, compréhensible par l’humain et par les machines et d’avoir une certaine norme.

Par exemple :

logger.info(“User 1234 clicked on the save button on the sign-up page”);

devient

logger.info({“userId”:”1234”, “buttonId”:”save”, “pageId”:”sign-up”, “message”:”button clicked by user”});

Le standard

Souvent on écrit des logs propres à une technologie, ce qui est une erreur. Pierre nous explique qu'elles ne devraient pas être propre à une technologie mais à une compréhension que l’on a de son infrastructure. Le nom des attributs doit être standard, cross-technologies. L’avantage est que si, par exemple, dans nos logs on a un attribut requestId, on peut filtrer dessus afin d’avoir toutes les logs reliées à cette valeur, peu importe la technologie. De plus, cela permet d’éviter de se demander, si demain on a une nouvelle technologie, comment rédiger les logs.

La normalisation

La normalisation permet de définir le format des données pour chaque attribut.
Par exemple : le temps de réponse en millisecondes, les dates au format YYYY-MM-DD, etc.

 

Exploitation des logs

Réfléchir à comment construire ses logs serait inutile si on ne les exploitait pas plus qu'en parcourant les fichiers de logs, comme il est fait habituellement. Ce serait même contre-productif car cela demanderait du temps pour refactorer le code et rendrait les fichiers de logs encore plus compliqués à lire.

L’objectif est donc d'exploiter les logs grâce à une solution de log management, afin de construire des tableaux de bord avec des graphiques et d'obtenir des informations plus simplement grâce à un outil dédié plutôt qu'en parcourant des fichiers texte.
On peut ainsi, d'un coup d’œil, visualiser combien d’utilisateurs se sont connectés à un instant t, combien de requêtes ils ont fait, les variations de temps de réponse, etc.

 

Pour résumer, en tant que développeur, quand on écrit des logs, il faut se demander en quoi elles vont nous être utiles, à notre équipe et aux personnes qui reprendront notre code. Bien définir ses logs, c’est faire en sorte que son système ne soit pas une boîte noire mais un système qui va fonctionner et communiquer en temps réel sur son état. Une infrastructure qui communique toujours de la même façon avec une certaine structure, un certain standard et une certaine norme a ainsi plus de chances d'être pérenne. Enfin, bien exploiter ses logs permet d’être proactif, de ne pas subir les remontées d’anomalies des clients, mais de les détecter en temps réel afin de les corriger rapidement.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *