Les 3 piliers de l'observabilité

L'arrivée de Docker, de Kubernetes et plus généralement de ce que l'on nomme le cloud natif a bousculé nos habitudes : de la manière dont nous écrivons notre code, dont nous le déployons, mais aussi de la manière dont nous l'observons ! Peu d'entre nous se préoccupaient de l'Application Performance Monitoring (APM) avant 2014, et je suis sûr que beaucoup ignorent encore ce qu'est une trace distribuée. Pourtant, avec nos applications dynamiques découpées en microservices et hébergées dans le cloud, il est de plus en plus difficile de faire l'impasse sur ce genre d'outils. Et le continuous profiler est justement l'un de ces précieux outils.

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.

Les métriques sont de loin, à mon humble avis, le signal le plus fascinant. Je vous l'accorde, elles sont aussi vieilles que l'informatique elle-même et pour cause : « ce qui ne se mesure pas ne s'améliore pas » [1]. Mais mesurer une chose est parfois un art, et dans les technologies de l'informatique, c'est un art qui a fondamentalement évolué ces dernières années. Non pas qu'on ne mesure plus les mêmes choses qu'il y a 20 ans, la charge d'un CPU et les IOPS ont toujours leur importance, mais on ne les aborde simplement plus de la même manière, surtout quand on vient à parler de systèmes distribués.