Plateformes d'observabilité : toutes identiques et pourtant si différentes ?

Une pléthore d'offres utilisent toutes le même argumentaire sans pour autant offrir des solutions équivalentes et galvaudent au passage le terme - pourtant nouveau - d'observabilité.

L’observabilité est née dans le monde des technologies cloud-natives, des architectures en micro-services et des systèmes distribués par les entreprises. Cette complexification des infrastructures a engendré, chez les entreprises, un besoin de monitoring plus spécifique et donc de solutions d’observabilité. En quelques années à peine, il est devenu LE sujet clé ouvrant les vannes budgétaires pour moderniser les outils des entreprises. Selon une étude menée par Insight Avenue en avril 2023 pour Cisco AppDynamics, l’observabilité des applications est désormais une priorité stratégique pour leur entreprise pour 85 % des responsables IT. De plus, 70 % des organisations exploiteront des solutions d'observabilité, afin d'accélérer leur prise de décisions, et ainsi gagner un avantage concurrentiel non négligeable en 2026 selon le cabinet Gartner.

Pour répondre à l’expansion massive de cette demande, toute l'industrie de l’observabilité mais aussi du monitoring s’est engouffrée dans la brèche. La conséquence ? Une pléthore d’offres utilisant toutes le même argumentaire sans pour autant offrir des solutions équivalentes et galvaudant au passage le terme - pourtant nouveau - d’observabilité.

Une base commune mais des fonctionnalités différentes

Toutes les entreprises sont à un niveau différent de maturité IT. Pour celles qui ont opéré leur transformation numérique et sont passées des machines virtuelles aux containers et maintenant au serverless, leur infrastructure ne peut plus être monitorée de la même manière. Avec ces technologies cloud-native, les techniques et les outils de monitoring conventionnels peinent à suivre les nombreuses voies de communication et interdépendances dans ces architectures distribuées. L’observabilité permet alors aux équipes de superviser plus efficacement les systèmes modernes et les aide à trouver et à connecter les effets dans une chaîne complexe pour remonter jusqu’à leur cause. 

Pourtant, malgré sa popularité au sein des entreprises, l’observabilité n’a toujours pas obtenu une définition officielle par les analystes du secteur. En conséquence, de nombreuses offres sur le marché libellées « observabilité » présentent des fonctionnalités très différentes. De plus, l’absence de définition claire mène à certaines dérives avec des solutions de monitoring déjà existantes rebaptisées pour l’occasion. Ces pratiques entretiennent la confusion entre monitoring et observabilité et sont de plus en plus qualifiées par le marché de pratiques d’« observability washing ».

Aujourd’hui, les différents acteurs de l’observabilité s’alignent sur les prérequis indispensables pour rendre un système observable : des logs, des metrics et des traces. Idem en ce qui concerne les outils qui composent une plateforme d’observabilité : un real-user monitoring, du synthetic monitoring, de l’APM et plus particulièrement du tracing distribué, de l'infrastructure monitoring et enfin une plateforme de log.

Or, c’est bien là où le bât blesse. En effet, chacun des éditeurs vient d'un historique différent alors que la façon dont les plateformes sont packagées est identique : « nous collectons les métriques, les traces et les logs avec OpenTelemetry, et notre back-end réunit l’APM, la supervision de l’infrastructure, la supervision des utilisateurs réels, la supervision synthétique, etc. ». Alors comment les entreprises peuvent-elles s’y retrouver ?

La rapidité, un paramètre devenu indispensable ?

Selon une étude menée en 2016 par Google, les entreprises pouvaient perdre jusqu’à 53 % de leurs clients si leurs transactions prenaient plus de 3 secondes. Que penser de la situation en 2024 ? Non seulement la vitesse est indispensable pour éviter de perdre du chiffre d’affaires, mais elle peut également en créer. Une autre étude de Deloitte montre que dans certains secteurs, et notamment celui du retail, une amélioration de 0,1 seconde des performances des applications mobiles peut se traduire par une augmentation de près de 9 % du montant moyen des commandes.

Chaque seconde – chaque milliseconde, même – compte. Il est donc primordial de savoir, par exemple, s’il y a une fuite de mémoire au niveau du conteneur X avant que Kubernetes ne le relance et qu’il fonctionne à nouveau comme prévu.

Cette rapidité, aujourd’hui indispensable, fait donc naturellement partie des promesses des plateformes d’observabilité mais toutes les approches se valent-elles ?

La plupart des solutions d’Observabilité annoncent récupérer les données en quelques secondes, cela peut sembler suffisant. Ce qu’elles ne disent pas, c’est que pour créer de la valeur à partir de ces données (générer une alerte, mettre à jour un dashboard…) elles utilisent une approche de type “batch”, beaucoup plus (trop?) lente rendant l'environnement supervisé “non observable” pendant de précieuses secondes. Ces batchs collectent, à chaque requête, un volume de données très important mettant en difficulté les solutions d’observabilité qui ont du mal à y faire face lorsqu’elles sont associées aux technologies cloud-natives.

Cette approche atteint ses limites dans des environnements en micro-services puisqu’elle ne peut pas gérer l’explosion de métadonnées de conteneurs à cause de la fréquence de rotation de ces derniers, et parce qu’elles ont été élaborées avant l’ère des applications cloud-native.

En opposition, l’architecture streaming va toujours récupérer les millions de points de données initiaux mais ne va pas recréer une requête volumineuse une minute plus tard. La requête persiste mais elle est mise à jour chaque seconde sur la base des nouvelles données par petits incréments. Cette approche n’est pas seulement plus efficace, rapide et évolutive, elle garantit également la capture de toutes les anomalies, d’un client impatient à une fuite de mémoire dans une fonction.

Pour conclure, il est donc essentiel que les entreprises de soulever le capot (de la conception architecturale) des plateformes d’observabilité qui présentent des architectures très différentes et ne recueillent pas les données de la même façon. Ces choix ont une implication directe sur leur stratégie d'observabilité.

Enfin, les entreprises devront aussi se poser la question de la manière dont les fameuses données d'observabilité sont collectées. OpenTelemetry (OTel) devient peu à peu la norme de facto. Cette méthode est à la fois légère et open source contrairement à certains agents propriétaires avec à la clé une meilleure sécurité et conformité des données, deux points cruciaux pour les entreprises. Là encore, il faudra soulever le capot. Être compatible avec OTel ne signifie pas être “OTel-native” (c’est-à-dire 100% basé sur OpenTelemetry pour la collecte des logs, métriques et traces) et le risque de se voir proposer rapidement un agent propriétaire, en plus de l’agent OTel, pour avoir accès à cette “fonctionnalité” est grand.