L’observabilité : depuis que ce mot est apparu sur nos écrans, chacun en refait la définition à son avantage. Par exemple l’acteur du marché qui propose des services de logs et traces ne parlera que de ces spécificités comme si elles permettaient de saisir l’ensemble du concept. Alors qu’aujourd’hui, véritablement il n’y a aucune solution unique d’observabilité.

Un métier de spécialistes

Nous pouvons proposer une définition la plus intégrée possible. Pour nous expert de la mesure, il s’agit de la collecte et l’exploitation de l’ensemble des éléments de mesures et données nécessaires à détecter un ralentissement ou indisponibilité, et surtout, permettant d’en déterminer la cause. On retrouvera :

• Les logs ;
• Les traces ;
• Les métriques systèmes issues du monitoring ;
• Les usages fonctionnels ;
• Les transactions visibles ou non (état, résultat, temps d’exécution)

Ce métier, réservés à des spécialistes, s’appuie sur trois piliers :

• Métriques et surveillance : les informations exploitables de votre application et de sa performance. Pas forcément le graph du CPU, mais par exemple des mesures DEM ;
• Enregistrement/Journalisation. Les événements doivent être enregistrés ;
• Le traçage. Le but est de capturer ce qui se passe au cours d’une exécution, surtout dans des systèmes distribués (une requête est envoyée à plusieurs micro services).

La bonne stratégie

La bonne solution, c’est de choisir un spécialiste pour chacun des piliers évoqués. Mais avant tout, il faut d’abord s’assurer que le système applicatif soit totalement « observable ». L’ensemble décrit ci-dessus n’est en effet possible que si la mise en place des journaux et les traces est rendue possibles dès le développement grâce aux choix techniques de l’application. Ce n’est pas le cas dans un grande partie des applications.

Chaque nouveau service ou fonctionnalité doit être développé en prenant en compte ce besoin d’observabilité. Elle doit être continue ou ne sera pas ! La plus grande erreur serait de mettre de l’observabilité sur une application non observable.

L’observabilité, c’est la capacité à mesurer les états internes d’un système en examinant ce qu’il produit. Un système est considéré comme « observable » si son état actuel peut être estimé uniquement en utilisant les informations de sortie, à savoir les données des capteurs.

L’IA, qui est très souvent mise en avant, présente aussi des limites. Elle n’est en effet possible que pour améliorer une situation qui s’est déjà produite, ce qui limite à ce jour son déploiement. Chaque contexte est nouveau et les solutions d’intelligence autonomes ne sont pas encore assez performantes.

Si l’application le permet, la solution MIP permet de remplir tous les objectifs relatifs au premier pilier.

Quel ROI pour l’observabilité (Business Vs Perfection technique) ?

Le premier pilier est facilement accessible via des mesures applicatives fonctionnelles et métriques systèmes mais les deux autres piliers requerront différentes étapes pour aller vers un système de plus en plus observable.

Se posera alors la question : quel ROI pour le développent à posteriori de fonctions pour améliorer l’observabilité de mon application si celles-ci ne servent pas directement à l’utilisateur.

Aucune solution à ce jour ne répondra à 100% à un système 100% observable. Il y aura toujours un manque. Et vouloir combler ce manque, ou une disponibilité à 101% coutera parfois plus cher que de s’autoriser une baisse de performance.

Une priorité : l’utilisateur !

Le point de vue de l’utilisateur est ainsi primordial. L’utilisateur est capable de donner une indication très claire de là où chercher le problème. Ce qui permet de participer à la construction d’une observabilité qui lui sera directement utile.

MIP et ses partenaires peuvent ainsi aider à construire l’observabilité en transparence et pragmatisme.