La supervision c’est bien, l’observabilité c’est mieux

Sans être totalement nouvelle, l’observabilité n’est pas encore une approche familière aux utilisateurs que nous rencontrons, peut-être parce qu’ils ne perçoivent pas en quoi elle se distingue – ou complète - la surveillance. Mais ne nous y trompons pas : l’observabilité est bien plus qu’un nouveau mot à la mode pour parler de surveillance, et un enjeu intéressant à considérer avec attention.

Quelle est la différence entre la supervision et l’observabilité ?

La supervision (monitoring) correspond au processus de collecte, d'analyse et d'utilisation des informations des équipements physiques et logiciels qui composent le SI, afin de suivre les progrès d'un programme vers la réalisation de ses objectifs, de détecter les éventuels dysfonctionnements et de garantir son fonctionnement optimal à tout moment. Ce suivi porte sur l'observation de paramètres spécifiques et peut fournir bien des données supplémentaires. Mais il est généralement considéré indépendamment du contexte plus large du système.

L'observabilité désigne, quant à elle, la capacité de comprendre l'état interne d'un système en analysant les données observables dont font partie les artefacts numérisés, tels que les journaux, les traces, les appels API, le temps d'attente, les téléchargements et les transferts de fichiers, qui sont générés lorsqu'une partie prenante prend une mesure quelconque. L'observabilité aide les équipes à analyser ce qui se passe afin de pouvoir détecter et résoudre les causes sous-jacentes des problèmes.

Si l’on devait résumer : la surveillance permet de connaître la situation d’un système, tandis que l'observabilité aide à déterminer plus précisément ce qui se passe et ce qu'il convient de faire.

Supervision ? observabilité ? Ou les deux ?

La question se pose alors de savoir quel modèle choisir pour son environnement… pour autant qu’il faille choisir entre les deux.

La supervision fournit une vue limitée des données du système en se focalisant sur des mesures individuelles, suffisantes lorsque les modes de défaillance des dits systèmes sont bien compris. En se concentrant sur des indicateurs clés, la surveillance remonte des informations relatives à la performance globale du système. Mais plus les applications et les équipements sont complexes, plus leurs modes de défaillance le sont aussi. S’il est facile pour un administrateur système de comprendre quel schéma peut conduire à une panne courante (par exemple un pic d’utilisation de la mémoire), il est en revanche souvent impossible de prévoir les failles des applications distribuées. Et c’est tout l’intérêt de l’observabilité : en étant en mesure de comprendre l’état interne d’un système, il devient possible de déterminer ce qui ne fonctionne pas, et les raisons de ce dysfonctionnement.

Attention toutefois ! Il ne suffit pas de faire une corrélation entre quelques métriques pour pouvoir réaliser un diagnostic dans les applications modernes. Au contraire même ! Ces applications modernes, toujours plus complexes, requièrent une visibilité accrue sur l’état des systèmes. Pour y parvenir, il faut donc combiner l’observabilité à un outil de surveillance puissant qui en devient un composant essentiel.

Les clés de l’observabilité

Pour comprendre ce qu’il se passe à l’intérieur d’un système, l’observabilité s’appuie sur ses journaux, ses métriques et ses traces.

-       Les journaux / logs regroupent les données relatives aux applications et au système qui fournissent des détails historiques sur les opérations et les flux, y compris ceux des réseaux sociaux. Les entrées du journal décrivent des événements et l’exploitation complète ces métriques en fournissant un contexte lorsqu’elles sont enregistrées. Par exemple, un message du journal signalera un pourcentage élevé d’erreur dans une fonction API. Mais il faut le coupler aux mesures sur un tableau de bord qui montrent un épuisement des ressources, pour analyser avec plus de précision le problème.

-       La métrologie représente les ensembles de mesures prises dans le temps – et il en existe de plusieurs types :

o   Les métriques de jauges qui mesurent une valeur à un moment précis dans le temps. Par exemple, le taux d’utilisation CPU au moment de la mesure est une métrique de jauge

o   Les métriques delta dans lesquelles la valeur mesure la modification depuis son dernier enregistrement. Les métriques mesurant le nombre de requêtes sont des métriques delta.

o   Enfin, les métriques cumulatives dans lesquelles la valeur augmente constamment au fil du temps. Une métrique des « octets envoyés » peut être cumulative puisque chaque valeur enregistre le nombre total d’octets envoyés par un service à ce stade.

-       Le traçage distribué est le troisième pilier de l'observabilité et représente le parcours des interactions utilisateurs ou applicatifs sur le système. Une application peut dépendre de plusieurs services, chacun ayant son propre ensemble de métriques et de journaux. Le traçage distribué est une technique de diagnostic qui consiste à observer les demandes pendant qu'elles se déplacent dans des environnements distribués. Dans ces systèmes complexes, les traces mettent en évidence tous les problèmes de performance qui peuvent survenir dans les opérations entre les microservices.

Une observabilité complète s’intègre aux pratiques DevOps et repose sur d'autres types de données que les seuls indicateurs clés. L’un des principaux défis pour le responsable informatique qui souhaite « observer » son système sera de trouver l’équilibre entre un manque de données et un excès d’informations réparties en silo ou non utilisables. Mais si elle y parvient – et c’est l’un des principaux enjeux de l’observabilité - une entreprise s’assure ainsi une plus grande fiabilité de son infrastructure IT, une visibilité améliorée de son architecture applicative distribuée assurant une meilleure sécurité et une meilleure expérience utilisateur indispensables à la croissance de leur activité.