Parmi les trois piliers de l'observabilité, s'il y en a bien un qui n'a pas besoin d'être présenté, ce sont bien les logs. Qui n'a pas son anecdote sur un print initialement utilisé par un développeur pour s'assurer du bon déroulement de son code qui finit par se retrouver dans le code en production ? Le log est réellement l'instrument qui nous permet de répondre à cette question rudimentaire, mais essentielle : que se passe-t-il dans mon code à l'instant t. Mais parce qu'il est simple à utiliser et flexible à souhait, le log pose souvent un réel problème lorsqu'une application passe en production. Et c'est encore plus vrai dans les systèmes distribués.
Dans l'article sur les 3 piliers de l'observabilité, j'ai dit qu'un log était un objet structuré, mais ça ne va pas de soi. Après tout, quelle est cette prétendue structure ? Il n'y a qu'à comparer un log Nginx avec un log PostgreSQL pour se rendre compte qu'ils n'ont rien en commun ! Nous allons en discuter plus avant, et peut-être cette discussion peut même nous amener à discuter ce qui pourrait faire d'un log un « bon » log. Mais je me rends compte en l'écrivant qu'avoir de bonnes pratiques concernant les logs n'a rien d'évident non plus, et qu'avoir un bon log est une chose peut-être fondamentalement différente que l'on soit un développeur ou un SRE. Et non seulement la personne à qui s'adresse ce log a une importance, développeur ou SRE, mais également le contexte : comme je l'ai dit en introduction, est-ce que le fait de faire tourner son application dans un conteneur ou d'être distribuée à une influence sur le format que doit prendre notre...
- Accédez à tous les contenus de Connect en illimité
- Découvrez des listes de lecture et des contenus Premium
- Consultez les nouveaux articles en avant-première
