L’ambivalence des plateformes d’observabilités : entre similitudes et divergences

Stéphane Estevez, EMEA Observability Market Advisor chez Splunk revient sur le sujet et partage son expertise.

Cette diversification complexe des infrastructures a créé un besoin urgent de solutions de supervision plus adaptées, entraînant une forte demande pour des outils d’observabilité. Rapidement, l’observabilité est devenue un élément central permettant de débloquer les budgets nécessaires à la modernisation des outils des entreprises. Une étude d’Insight Avenue, publiée en avril 2023 pour AppDynamics, révèle que 85% des responsables IT considèrent l’observabilité des applications comme une priorité pour leur entreprise. De plus, selon le cabinet Gartner, 70 % des entreprises prévoient d’exploiter les solutions d’observabilité pour améliorer leur prise de décision et accroître leur compétitivité d’ici 2026.

Face à l’explosion de la demande, l’ensemble des acteurs de l’industrie de l’observabilité et du monitoring a cherché à se positionner sur le marché. Seulement, voilà le hic :  l’ensemble des solutions avancent le même argumentaire mais n’offre pas les mêmes fonctionnalités, diluant ainsi la notion encore émergente d’observabilité.

Un socle commun, des capacités variées

Le niveau de maturité en matière d’informatique diffère selon les entreprises. Pour celles qui ont réalisé leur  transformation numérique, en passant des machines virtuelles aux conteneurs et maintenant au serverless, la surveillance de leur infrastructure nécessite une approche différente. Les méthodes et outils de monitoring traditionnels ne permettent de superviser facilement les technologies cloud-native. En effet, elles peinent à gérer les nombreuses voies de communication et les interdépendances dans ces architectures distribuées. L’observabilité est donc devenue LA solution permettant aux équipes de surveiller plus efficacement ces systèmes modernes et de retracer les effets dans une chaîne complexe pour identifier leurs causes profondes.

Si l’observabilité a été adoptée avec succès par de nombreuses entreprises, elle n’a pas encore trouvé de définition officielle auprès des analystes du secteur. Cette absence de clarté conduit à des variations significatives entre les offres, notamment en ce qui concerne les fonctionnalités proposées. Ce manque de précision engendre des confusions : par exemple, certaines organisations réutilisent délibérément des solutions de monitoring existantes en les requalifiant simplement sous le terme d’observabilité. Ainsi, les frontières entre monitoring et observabilité deviennent floues, donnant lieu à un nouveau phénomène  : l’« observability washing ».

En conséquence, les acteurs du marché ont définis trois prérequis permettant de définir l’observabilité : les logs, les metrics et les traces. Ils se sont également alignés sur les outils qui doivent composer une plateforme d’observabilité : un real-user monitoring, du synthetic monitoring, de l’APM et plus précisément du tracing distribué, de l’infrastructure monitoring et enfin une plateforme de log.

Toutefois, c’est là que le problème se pose : les éditeurs, tous ayant des antécédents diverses et variés, présentent leurs plateformes comme étant similaires : «les métriques, les traces et les logs sont collectées avec OpenTelemetry, et notre back-end intègre l’APM, la supervision de l’infrastructure, la surveillance des utilisateurs réels, la surveillance synthétique, etc. », pouvant mener les entreprises à choisir une solution d’observabilité qui n’en est pas vraiment une.

Le maître mot : la rapidité

D’après une étude de Google publiée en 2016, le risque pour les entreprises de perdre des clients si leurs transactions prenaient plus de 3 secondes s’élevaient à 53%. Qu’en est-il en 2024 ? La course à la rapidité n’a jamais été aussi intense : il ne s’agit pas seulement de prévenir les pertes de chiffre d’affaires, mais aussi de générer davantage de revenus.

En outre, une étude de Deloitte révèle que, dans certains secteurs comme le retail, une amélioration de 0,1 seconde des performances des applications mobiles peut entraîner une augmentation de près de 9 % du montant moyen des commandes.

Une seconde voire même une milliseconde peut faire toute la différence. Disposer d’une vision d’ensemble sur les systèmes est donc crucial. Par exemple, s’il y a une fuite de mémoire au niveau du conteneur X, il est utile de le savoir avant qu’il ne soit relancé par Kubernetes pour qu’il fonctionne de nouveau.

La rapidité est aujourd’hui intrinsèque à la promesse des plateformes d’observabilité. Pour autant, toutes les approches ne se valent pas forcément.

La majorité des plateformes d’observabilité affirment collecter les données en quelques secondes. En revanche, elles se cachent bien de préciser que pour créer de la valeur à partir de ces mêmes données, elles se servent d’une approche de type « batch », qui elle est beaucoup plus lente, rendant l’environnement monitoré « inobservable » le temps de quelques précieuses secondes. A chaque demande, ces batchs récupèrent un grand nombre de données, perturbant ainsi la mission des solutions d’observabilité qui peinent à trouver une issue dans le cas où elles sont combinées aux technologies cloud-native.

La limite de cette approche est d’autant plus flagrant dans les environnements en micro-services, puisque la solution d’observabilité rencontre de grandes difficultés à gérer le volume trop important de métadonnées de conteneur. Les raisons : leur fréquence de rotation et le fait que les données aient été générées avant l’ère des applications cloud-native.

À l’inverse, l’architecture streaming traite en continu les millions de points de données initiaux sans nécessiter une nouvelle requête volumineuse après une minute. La requête reste active et se met à jour en temps réel, en intégrant progressivement les nouvelles données. Cette approche est non seulement plus efficiente, rapide et évolutive, mais elle garantit aussi la détection de toute anomalie, qu’il s’agisse d’un client impatient ou d’une fuite de mémoire dans une fonction.

En conclusion, il est crucial pour les entreprises d’examiner attentivement l’architecture des plateformes d’observabilité, car celles-ci varient considérablement et n’ont pas les mêmes méthodes de collecte des données. Ces différences influencent directement leur stratégie d’observabilité.

Par ailleurs, les entreprises doivent également se pencher sur la façon dont les données d’observabilité sont collectées. OpenTelemetry (OTel) s’impose progressivement comme la norme de facto, offrant une solution légère et open source, contrairement à certains agents propriétaires. Cela garantit une meilleure sécurité et conformité des données, des aspects essentiels pour les entreprises. Toutefois, il est important de rester vigilant : être compatible avec OTel ne signifie pas nécessairement être « OTel-native » (c’est-à-dire entièrement basé sur OpenTelemetry pour la collecte des logs, métriques et traces). Le risque de se voir imposer un agent propriétaire supplémentaire pour accéder à certaines fonctionnalités demeure réel.