LogHash, une meilleure façon de journaliser
Tous les développeurs que je connais, quel que soit leur langage ou leur plateforme, produisent un jour des logs. Certains sont très structurés, d’autres ne sont que du texte brut. Ils peuvent servir d’outil de débogage ou être au cœur d’infrastructures complexes. Aujourd’hui, je vais parler de la manière de mieux exploiter les logs en texte brut.
L’enfer des logs
Lorsque toute une équipe utilise des logs, ceux-ci s’accumulent inévitablement et deviennent de plus en plus difficiles à manipuler, à parcourir ou à traiter. La plupart d’entre nous finissent par utiliser Ctrl/Cmd+F pour retrouver la ligne qu’ils viennent d’ajouter.
Quelques mois plus tard, en recherchant un bug ou en travaillant sur du code ancien, vous héritez de tous ces messages dans la fenêtre de sortie de Visual Studio, les logs Adb, NSLogger ou un stockage de tables, ElasticSearch, Kibana, etc. Il vous faudra du temps pour leur donner du sens. Vous y arriverez, bien sûr… au bout d’un moment.
Tous ces logs « techniques/de débogage » finissent par n’être lus que par les développeurs et quelques membres aventureux de l’équipe informatique. Le service marketing ou growth hacking vous demande des statistiques, des tunnels de conversion et des cohortes ? Aucun problème ! Ajoutez un marqueur MixPanel, kissmetrics, flurry [insérez ici votre plateforme d’analyse SaaS], et basta. L’équipe design demande une fonctionnalité de suivi des utilisateurs ? Ajoutez la bibliothèque Optimizely. Vous, l’équipe de développement, voulez suivre les bugs de votre application Android ? Il y a Crittercism pour ça…
Mais combien d’informations nécessaires à toutes ces solutions sont déjà là, au milieu de vos logs techniques ?
Le besoin d’un « Markdown pour les logs »
Pour extraire toutes ces informations de vos logs, il faut les structurer. Il vous faut des logs sémantiques ! Si vous regardez le Semantic Logging Application Block de Microsoft P&P (1), vous découvrirez le véritable coût de la journalisation sémantique : pour l’instant, cela signifie une classe par information à journaliser. C’est tout simplement l’enfer.
Il nous faut une solution sémantique qui :
- fonctionne sur toutes les plateformes, dans tous les langages et pour tous les types d’applications ;
- ne nécessite pas de changements lourds dans la chaîne de traitement des logs ;
- soit si simple que quelques frappes au clavier suffisent à commencer ;
- puisse être adoptée par un seul développeur dans une équipe, puis se généraliser.
Aujourd’hui, je publie la première version des spécifications du langage de balisage LogHash, un langage de balisage inspiré de Markdown pour vos logs.
Vous pouvez les consulter sur le dépôt GitHub de LogHash. N’hésitez pas à contribuer ou à ouvrir une issue si vous avez une question ou une remarque.
Cela fait maintenant plus de six mois que je travaille sur ce langage et que je le teste, en le mettant à l’épreuve dans les applications mobiles de Deezer. J’ai déjà gagné beaucoup de temps en développant ou en déboguant des fonctionnalités. Il est temps de voir s’il peut aussi être utile à d’autres ;).
Et maintenant ?
DES OUTILS ! Pour tirer le meilleur parti de ce langage, il faut un parseur, puis un outil permettant de l’exploiter. J’ai déjà réalisé les prototypes de deux parseurs, l’un en C# et l’autre en JavaScript. J’ai également créé un petit complément Visual Studio qui remplace la fenêtre de sortie et ajoute des fonctions de recherche et de filtrage.
La toute prochaine étape est de publier un outil Web pour explorer vos propres logs LogHash. Suivez-moi sur Twitter pour être parmi les premiers à l’essayer ;).
Je vais aussi reprendre mon complément Visual Studio de zéro : le premier essai est rarement le bon, surtout lorsqu’on travaille sur des compléments COM pour Visual Studio ou Office :).
En attendant, vous pouvez essayer de loghasher vos logs et me dire ce que vous en pensez.
(1) : J’ai participé à la revue de l’Enterprise Library 6, dans laquelle SLAB a été introduit.