L’observabilité est plus qu’un nouveau mot à la mode ou une nouvelle génération d’outils de monitoring, c’est un changement de paradigme. Jusqu’à maintenant l’approche naturellement adoptée pour superviser les systèmes informatiques traitait ces systèmes comme des boîtes noires, dont on ne voit pas le contenu.

On ne pouvait donc mesurer que des symptômes sans vision claire sur les causes de leurs comportements. Les systèmes devenant plus complexes et distribués, se contenter de superviser les ressources systèmes de bas niveau de l’infrastructure, par exemple, n’est plus pertinent.

Qu’est-ce que l’observabilité ?

L’observabilité consiste à instrumenter nativement les applications et les infrastructures pour leur permettre d’exposer en temps réel leur propre état opérationnel et leur performance. En d’autres termes, leur état de santé.

Le système est dit “observable” lorsqu’il fournit un ensemble de données permettant de savoir à tout moment dans quel état interne il se trouve. Mieux, le système devient prévisible, car l’analyse de ces indicateurs permet de rendre ses entrailles transparentes et de percevoir clairement les interactions de causes à effets qui s’y déroulent.

Que suppose la mise en place d’une démarche d’observabilité ?

Je conçois l’observabilité comme une propriété d’un système, au même titre que la sécurité ou la haute disponibilité. De la même façon qu’on conçoit une application pour qu’elle soit fiable, qu’elle s’auto répare, qu’elle soit robuste, on conçoit l’application pour qu’elle soit observable, c’est à dire “transparente”.

Cela va imposer des contraintes sur son architecture, la manière dont sont organisés ses composants : l’application doit être conçue pour fournir elle-même des informations sur la santé de chaque composant, ainsi que la performance de leurs interactions. C’est une rupture avec ce qui se faisait jusqu’à maintenant, où l’observation et la supervision étaient reléguées à des systèmes extérieurs à l’application.

La différence avec la supervision, c’est que la supervision consiste à envisager ce qui pourrait mal se passer, anticiper les possibles problèmes et mettre en place de l’alerting lorsque ces scénarios se produisent. Cela suppose une expérience préalable du système : on imagine le futur à travers le prisme d’incidents passés sur des systèmes similaires, on intervient alors en réaction aux événements.

Il est important de noter que l’activité de supervision fait partie de l’observabilité, mais ça n’en est qu’un sous-ensemble. La démarche de mise en œuvre de l’observabilité va au-delà de la mise en place de systèmes d’alarme.

Quels indicateurs doit-on mesurer ?

C’est l’une des questions les plus populaires : “mais par où je commence ?”. Pour cela, il faut savoir pourquoi on fait les choses. Dans quel but construit-on ce système ou cette application ? Quel problème doit-on résoudre ? Qu’essaie-t-on d’améliorer ?

Répondre à ces questions nous permettra de savoir ce qu’on doit mesurer en priorité, et les informations dont on a besoin. La première chose à mesurer, c’est de savoir si on répond à l’objectif du projet. On touche ici à la notion de KPI bien sûr, ces fameux indicateurs de performance qui sont là pour vérifier la pertinence d’un système et son “acceptabilité”. Cependant, si ces indicateurs sont importants à mesurer, il faudra également savoir les expliquer, surtout lorsqu’ils ne sont pas bons, c’est-à-dire qu’ils se rapprochent dangereusement de la limite de l’acceptable.

D’autres indicateurs seront donc nécessaires, moins visibles mais indispensables pour comprendre pourquoi le système se dégrade ou bien même s’améliore. Et c’est ainsi, qu’en descendant dans les couches du système, on identifie d’autres points de mesure supplémentaires et indispensables pour le rendre “transparent” et “explicable”.

Un autre point important sur le choix des mesures correspond à leur valeur. Rappelons-nous que l’objectif est de pouvoir expliquer le comportement du système dans chaque situation. Il n’est donc pas toujours nécessaire d’avoir des points de mesure exacts, par contre les changements observés sur ces points de mesures devront être corrélés avec les changements de comportement du système entier. On sera donc d’autant plus attentif aux changements de comportement des indicateurs dans le temps (points d’inflexion, augmentation/diminution subites, périodicité) qu’à leur valeur exacte à un temps donné.

C’est également là que l’approche par l’observabilité diffère de celle de la supervision, c’est par l’analyse des changements de comportement que l’on s’approprie le système observé. On ne s’y intéresse plus seulement quand il ne va pas bien (alarmes), mais tout le temps (graphiques), même quand il va bien.

Et au-delà des indicateurs ?

De mon point de vue, c’est un mode de conception dans son ensemble. Cela inclut la documentation par exemple, afin de rendre le système qu’on vient de mettre en place compréhensible, “transparent”. Décrire le fonctionnement du système c’est d’abord documenter son objectif, mais surtout de mettre en avant ses limites de fonctionnement. Quand on parle de documentation, ce n’est pas uniquement sous la forme d’un document rédigé mais c’est aussi un code bien conçu, lisible, où les opérations codées sont claires (nommage des fonctions, des variables, etc.). Tout ceci, pour rendre le système plus compréhensible, et donc plus observable.

Côté infrastructure as code, idem, les ressources sont nommées selon leur appartenance et leur raison d’exister. On cherchera pour cette démarche à garantir la traçabilité des actions sur l’ensemble des ressources, de pouvoir savoir qui a créé quelle ressource, et pourquoi. Évidemment, l’automatisation est un plus parce que le code est lui-même un type de documentation constamment à jour, mais à condition qu’elle soit elle-même conçue pour être observable.

Quelles sont les implications de l’observabilité en termes d’organisation ?

Il ne sert à rien de mettre en place une démarche d’observabilité si on ne s’assure pas que le système sera bien observé, c’est à dire que quelqu’un s’intéresse aux informations remontées. Derrière cette démarche, on doit se poser la question de la valeur attendue des informations issues de l’observabilité.

S’il est établi que la dégradation des performances, et le temps passé à identifier ces problèmes, a de la valeur pour l’entreprise, alors une démarche d’observabilité aura du sens. Il est nécessaire d’estimer ce besoin, car dans la mesure où l’observabilité est une propriété du système, qui doit être prise en compte dès la conception, cela a un coût pour l’entreprise. Ce n’est pas tant une question d’argent que de temps, celui qu’on prendra lors de la conception du projet pour y inclure la démarche, et celui qui sera pris pour la surveillance des dashboards produits par l’observabilité.

Cela pose la question de l’ownership du projet : qui est responsable du système, qui assume la surveillance de ces dashboards, qui souhaite apprendre, comprendre et anticiper les comportements du système en fonction des aléas de son utilisation et des incidents de production ?

Les outils ne sont que des outils, ils facilitent la remontée et la présentation des mesures, mais identifier quelles sont les informations nécessaires et interpréter l’évolution des tendances est encore un travail humain. On ne peut pas améliorer ce qu’on ne mesure pas.

Article initialement publié dans le hors-série reBirth, à télécharger ici.