En général, les entreprises et les vendeurs ont du mal à s’accorder sur le concept d’observabilité suivant qu’ils viennent du réseau, du suivi d’applications, de la sécurité... De la même manière, les clients utilisent le mot observabilité avec de nombreux sens différents, suivant leur maturité et leurs besoins.
Stéphane Estevez, EMEA Observability Market Advisor chez Splunk n’y va pas par quatre chemin. « Aujourd’hui, tout le monde parle d’observabilité, tout le monde utilise les mêmes mots clés. Chez mes confrères ou même chez Splunk, on est dans le même cas, tout le monde dit : C’est du ‘end-to-end’ de visibilité, c’est du real-time… Mais personne ne dit comment. Au final, c’est impossible pour un DSI de prendre une décision sans être obligé de gratter vraiment la surface. Donc, un des problèmes, c’est la terminologie. Quand les clients eux-mêmes parlent d’observabilité, souvent, il s'agit de télémétrie, de monitoring. Ce n’est pas vraiment de l’observabilité. Que ce soit chez les vendeurs, chez les intégrateurs, chez les clients, personne n’est d’accord sur ce que c’est. »
Alexandre Signoret, en charge de l’offre d’observabilité et AIOPs chez IBM, est du même avis. « Je sens exactement la même chose. Je pense que le marché est confus, et il est confus parce que je pense que les clients sont encore à la recherche de la direction que ça va prendre. Les éditeurs aussi ont leur part de responsabilité par leur message marketing et l’approche qu’ils ont aujourd’hui, on a l’impression que l’observabilité est un outil pour répondre à tout en essayant de faire tout rentrer dedans.»
Thomas di Luccio, Product Manager chez Platform.sh mais venant de BlackFire, un outil d’observabilité racheté par Platform.sh, perçoit deux types de population face à l’observabilité : «Il y a les pompiers, ceux qui n’ont pas investi dans l’observabilité. Ils ont vu la performance comme un « nice to have », un truc en plus dont on peut se passer, parce que l’énergie doit se mettre à créer des fonctions. Et forcément, il y a eu un lancement de produits, il y a eu une offre commerciale, Black Friday, des offres saisonnières, et tout s’est effondré. On a perdu énormément d’argent avec une vente qui s’est loupée, et ils viennent parce qu’il y a une crise. Il y a une autre catégorie de gens, malheureusement moins nombreux, qui ont une vision plus proactive de la relation à la performance. Donc ils viennent à l’observabilité par la question de la performance, du contrôle. Ils disent : «OK, la performance est une fonction intégrante du produit qu’on crée, donc on a besoin d’être en contrôle.» Et pour être en contrôle, on a besoin de comprendre qu’est-ce qui peut bien se passer dans nos applications, qu’est-ce qui peut bien se passer dans nos serveurs qui font que, de temps en temps, ça frictionne, on n’arrive pas à comprendre pourquoi, et on a besoin de cette capacité à observer les systèmes. En tout cas, moi, je le définis comme ça. Je sais qu’il y a un flou là-dessus. Moi, je le définis comme une exception assez large. C’est une capacité. On offre la capacité à voir dans les systèmes.
Une utilisation émergente
Si le sujet fait beaucoup parler et écrire, les entreprises entament juste le chemin vers l’observabilité. Selon une étude réalisée pour le compte d’OpsRamp, une société dans le giron d’HPE, 30 % des répondants indiquent explorer les cas d’usages adéquats pour l’observabilité. Seulement 24 % ont mis en œuvre une suite d’outils d’observabilité complète dans plus de 90 % de leur organisation, dont 19 % que dans certaines entités de l’entreprise. Les outils en place servent plus particulièrement à observer les applications dans le cloud ou nativement cloud (61 %). La moitié les utilise dans des environnements hybrides ou pour des questions de sécurité. Un peu moins (47 %) l’utilisent pour suivre le réseau. 34 % indiquent cependant suivre l’ensemble du système informatique.
Les coûts conditionnent l’usage
Selon la même étude, les coûts de licences mènent l’utilisation. De ce fait, à 49 %, les entreprises choisissent une formule à prix fixe dans le cadre d’accord entreprise. Seulement 12 % prennent la formule « pay as you go ». Du fait du volume de données et autres éléments corollaires, les entreprises font le choix de prévoir les coûts quand elles mettent en place l’observabilité. De plus, les outils sont considérés comme chers et la question des coûts et du retour sur investissement reste centrale dans les projets (53 %). Le premier point d’attention reste cependant les données. Le volume des données à gérer et à stocker est trop important pour un usage ou une analyse effective (57%). A la même proportion que les coûts se placent la précision des données et les problèmes de faux positifs. La courbe d’apprentissage des outils avant de pouvoir les utiliser efficacement est aussi un point cité. Viennent ensuite la peur autour de la suppression de certains postes et la longueur des cycles d’implantation.
Un autre point problématique est l’écart entre les bénéfices attendus et la réa lité. Le premier bénéfice attendu reste encore l’amélioration de la performance des applications et de l’expérience des utilisateurs. Cela peut s’expliquer par le fait que la plupart des outils du marché proviennent d’acteurs historiques du monitoring de la performance des applications. Ce point est largement devant l’autre bénéfice attendu, l’amélioration de l’efficacité de l’automatisation dans l’ensemble de l’organisation. A égalité suivent une attente sur des déploiements plus rapides des applications avec moins de problèmes et d’arrêt de production et la détection de problèmes complexes. Certains s’attendent même à une détection proactive des problèmes. Plus généralement, ils attendent une meilleure efficacité opérationnelle. Pour beaucoup les objectifs sont atteints. Ainsi, 59% des personnes interrogées dans cette étude indiquent avoir la capacité des problèmes de performance qu’ils ne connaissaient pas et de répondre aux problèmes avant que les utilisateurs soient impactés. Viennent ensuite la possibilité de contrer des attaques, l’amélioration de la performance des applications, le retrait d’applications héritées et la réduction des dépenses du service IT avec une modernisation des applications ou de l’architecture.
Rénover le monitoring
Interrogées sur les outils qu’elles remplaceraient en premier après la mise en place de l’observabilité, les entreprises répondent quasiment aux deux tiers le monitoring du réseau qui arrive largement devant les outils de gestion de la performance des applications, du suivi de l’infrastructure, du cloud ou de l’expérience utilisateur. En fait, les entreprises utilisent l’observabilité, non pas pour remplacer les outils de monitoring en place, mais le complète pour le rendre meilleur. Les entreprises réalisent cette opération par le biais d’intégration avec les outils de monitoring IT, les logiciels d’automatisation des processus, la gestion des événements ou des incidents et l’AIOps. Ceux qui profitent le plus de cette mise en œuvre sont les équipes d’analyse des données et le management devant les équipes opérant le cloud. Suivent les équipes de sécurité et les équipes de développeurs, que ce soient les DevOps ou les développeurs classiques d’applications
Des données plus critiques que d’autres
Les entreprises ayant répondu à l’étude d’Opsramp placent en tête les métriques comme étant les données les plus critiques dans leur travail (charge CPU, usage mémoire, taux d’erreur systèmes...). De nouvelles s’ajoutent désormais comme le calcul des coûts du cloud, la consommation énergétique. En fait, tout ce qui peut se mesurer en chiffres est appelé à devenir une métrique. Les logs suivent de près devant les événements
et les traces. La plus faible présence des traces comme données critiques résulte de la moindre présence d’applications en micro-services ou serverless. En conséquence, les applications créent moins de traces. Si cela semble être le futur, l’étude indique que les entreprises adoptent ce nouveau type d’application lentement et ont actuellement moins besoin des traces que d’autres indicateurs comme les métriques ou les logs.
De nombreux outils pour des tâches différentes
Selon leur cœur de métier d’origine, les outils d’observabilité servent des objectifs différents. Suivant les besoins et objectifs attendues, il est nécessaire de faire une étude précise sur les outils qui ne font forcément pas tout. Les outils présents sur le marché ont des origines et des fonctions souvent très différentes. Nous présentons ici quelque exemple de ce qu’il est possible de trouver sur le marché sous le vocable d’Observabilité.
Yann Samama, Senior Sales Engineer chez Gigamon, indique : « Notre approche chez Gimanon c’est vraiment l’observabilité, c’est ce qu’on voit sur le réseau. Nous estimons que l’intérêt de voir ce qui se passe sur le réseau, c’est que ça donne la réalité des choses, et ce n’est pas juste une estimation de ce qu’il peut être ». Il continue : « Donc, si on part du principe que le réseau est un peu comme une espèce d’organisme semi-vivant, qui évolue avec sa propre logique intrinsèque, on est obligé de l'observer pour comprendre ce réseau, pour détecter des menaces éventuelles, pour valider son bon fonctionnement et sa pérennité. Le réseau n’est pas fait pour s’auto- observer, pour s’auto-diagnostiquer. Donc, on a besoin d’aller chercher les informations qui transitent, pour avoir la véracité de ce qui se passe en temps réel, pour prendre les décisions qui s’imposent. Le rôle de Gigamon là-dedans, c’est capturer les paquets, les agréger, éventuellement les filtrer ou les modifier pour apporter un peu plus de valeur dans la chaîne, et enfin les envoyer à des outils. Et ces outils, ça peut être des outils d’observabilité classiques, NPM, APM, comme des outils d’observabilité qui sont orientés sécurité. Et l’idée pour nous, c’est d’être agnostiques. C’est-à-dire qu’on fournit la matière première, et vous en faites votre substantifique moelle, et vous la développez de la manière qui vous semble la plus propice à vos utilisateurs. »
Easyvista se veut plus modeste en jouant la carte de l’intégration avec d’autres outils, et conserve une forte empreinte huper ou supervision en particulier sur l’infrastructure.
Chez IBM, c’est un ensemble de logiciels, souvent issus d’acquisition comme Turbonomics, Apptio qui apporte la complétude, la vision et une observabilité à plusieurs facettes. IBM a de plus développé une console d’agrégation des données de différentes applications sources et de corrélation des données, IBM Concert. Le logiciel a des fonctions de découvertes, de compréhension en s’appuyant sur Watsonx. Il peut proposer des recommandations à l’issue d’un prompt dans un outil d’intelligence artificielle générative, et peut prendre des actions de manière autonome ou remédier à un processus défectueux.
Yves Le Berre chez ALE indique : « On va agréger aussi les logs divers et variés, les logs d’accès aux machines, les logs des applicatifs et on va agréger aussi tout ce qui est traces d’interaction qui vont nous permettre ce qu’on va appeler aussi des APM, et d’avoir une vision sur la performance de la softisation. Un exemple : on fait des services équivalents à ceux qu’on utilise aujourd’hui, Google Meet, Rainbow, c’est un service de collaboration, de communication. Typiquement, on va vérifier entre la requête de monter par exemple une vidéoconférence, on va aller vérifier le KPI, qui est le temps entre le moment où l’utilisateur va déclencher la conférence et où tous les services vont être mis ensemble pour délivrer le service. On va aller monitorer le temps de réponse, ce qui va donner une indication sur la moyenne, sur le temps, sur ce qu’on est capable de faire et si on se rend compte qu’il y a un délai supplémentaire sur la mise en service, par exemple des serveurs de conférences, on va se poser la question est-ce que c’est un phénomène transitoire, une problématique réseau, une problématique data center, est-ce qu’on manque de serveurs dans la zone, est-ce qu’il ne faudrait pas en rajouter d’autres ou est-ce qu’on a une perte de performance sur un des composants ? ». Il ajoute : « sur Rainbow, on a environ un peu plus de 700 alarmes qui sont mises en place, qui sont cascadées sur la chaîne des métriques qu’on va concentrer, qu’on va agréger avec Prometheus. On va associer Prometheus avec l’alert manager et on va effectivement povoir définir des seuils ou des scénarii, donc un enchaînement d’évolutions de KPI qui vont déclencher les alertes et enclencher nos équipes d’opération si on dépasse le gabarit ».
Thomas di Luccio, Developer Relations Engineer chez Platform.sh, fait découvrir un autre prisme de l’observabilité. « On fait de l’observabilité côté applicatif, donc concentré essentiellement sur les web apps, PHP Python, c’est notre cœur de métier. On commence à gérer un peu plus de runtime, mais ça reste essentiellement des applications découplées PHP Python ». Il continue : « nous réalisons du profiling déterministe, du continuous profiling,
donc du profiling probabiliste. Cela veut dire que vous pouvez anticiper comment devrait se comporter une application ». Il ajoute : « Blackfire va envoyer des requêtes dans l’environnement que vous avez désigné, faire l’ensemble de ses actions, mesurer la performance de ses actions, et évaluer ça par rapport à ce que vous avez défini. Parce que vous avez défini qu’il fallait que ça se passe en tant de temps, que ça consomme autant de requêtes SQL, que ça fasse tant de CPU, tout ce que vous voulez. Et ça, vous allez pouvoir le rejouer tout le temps.
On est dans la proactivité quand les développeurs ou les équipes de développement vont pouvoir tester ça, et d’interdire de fusionner leur travail, de le mettre en production, si cela dégrade la performance. On offre la possibilité d’être dans le contrôle ».
Autre approche, celle de Riverbed : « on regarde le sujet du point de vue de l’utilisateur. Donc, l'expérience qu’il va avoir, la performance qu'il va assurer pour le business, le business qui va qui va diminuer ses coûts et améliorer ses revenus, ainsi de suite. Tout commence dans le poste de travail avec l’utilisateur quand il va cliquer quelque part. Donc, il va par exemple cliquer pour sortir une liste de clients ou bien cliquer pour sortir une liste de son inventaire qui est en stock, ainsi de suite. D’abord, ça commence par le poste de travail où il va faire ce clic pour demander, je veux la liste des clients ou bien je veux mon inventaire. Cette requête, la deuxième étape, elle va passer dans un réseau, dans un réseau WAN, dans un réseau LAN, pour arriver après à l’application. La deuxième partie après le poste de travail qu’il faut surveiller pour avoir une bonne observabilité, c’est la partie réseau.
Donc, l’accès à l’application. Une fois qu’on arrive à l’application, il y a la partie Application Performance Monitoring avec l’analyse de code, ainsi de suite, pour s’assurer que l’application ou bien la requête s’exécute comme il se doit dans l’application. Mais ça ne s’arrête pas ici car l’application est hébergée sur un serveur, donc il faut aussi surveiller l’infrastructure. Si je veux aujourd’hui assurer que mon application métier tourne bien, il faut avoir une vision globale. On ne peut pas parler d’observabilité globale juste si on regarde l’application. Il faut regarder l’infrastructure où l’application est installée, il faut regarder le réseau d’accès sur lequel on peut avoir accès à cette application et ensuite, il y a le poste de travail de l’employé qui l’utilise pour accéder à cette application. Aujourd’hui, c’est ça notre vision chez Riverbed. Notre vision, c’est de partir sur du Unified Observability. On dit qu’on fait du Digital Experience Management ou bien Digital Employee Experience sur le poste de travail qui va nous amener le côté observabilité sur le poste de travail », détaille Joseph Slameh, director Solutions Engineering chez Riverbed.
Les apports de l’IA et d’Open Telemetry
L’AIOps s’enrichit des nouvelles technologies d’intelligence artificielle et devient omniprésente dans les outils. De plus, une nouvelle approche est soutenue avec l’avènement d’un standard de fait : Open Telemetry.
Du fait de différentes problématiques comme simplifier la remédiation ou l’identification des incidents le volume des données à traiter, le manque de pour des personnels peu qualifiés. Elle sert principalement ressources spécialisées, les différents silos de à des fonctions d’automatisation. Si les éditeurs reculent données, les outils d’observabilité ont de plus encore à la rendre totalement autonome, elle peut d’ores et en plus recours à l’intelligence artificielle sous déjà prendre des actions seules sur des processus simples toutes ses formes. Cela reste principalement et encadrés. Elle est désormais présente dans la majorité des outils des outils sur le marché. Ceux qui ne l’ont pas encore marché intègrent des fonctions prédictives et bénéficient intégrée vont certainement le faire dans les semaines ou des apports de l’intelligence artificielle générative pour les mois à venir.
Un standard de fait
L’introduction d’OpenTelemetry (OTel) représente une véritable révolution pour l’observabilité dans le monde IT, puisque ce nouveau standard ou « framework » open- source consiste en une collection d’APIs, SDKs et outils pour instrumenter, générer et traiter des données sur la performance venant des logs, des traces ou des métriques dans un format unique et unifié, et facile à consommer par les développeurs. Le standard est maintenu par la CNCF (Cloud Native Computing Foundation) et est en train de devenir la norme de mise à disposition des données d’observabilité dans le cloud-native.
OpenTelemetry permet une approche normalisée et plus intégrée par rapport aux outils de monitoring traditionnels. Alors que ces derniers nécessitent une mise en place manuelle en connaissance de l’infrastructure, OpenTelemetry permet une instrumentation automatisée et dynamique garantissant l’observabilité en temps réel. Cette nouvelle norme est aujourd’hui clé dans la mise en œuvre d’une plateforme d’observabilité moderne permettant de mieux anticiper les problèmes, d’identifier en temps réel les signaux issus de l’ensemble de la chaîne applicative et d’apporter de la proactivité. Grâce à la capture automatisée et en temps réel des métriques, traces et logs au sein des environnements dynamiques et hybrides, les équipes IT peuvent s’apercevoir d’une détérioration d’un service dès l’instant où il devient visible. Ils peuvent donc anticiper et résoudre les problèmes avant qu’ils n’impactent réellement les utilisateurs. Cela permet une gestion plus fine et agile des infrastructures, où l’identification de signaux faibles devient un levier essentiel pour une meilleure prise de décision. Avec l’introduction d’OpenTelemetry, la manière
dont les systèmes en production sont gérés se change au fur et à mesure. Où OTel n’était d’abord utilisé que pour les applications cloud-natives, on commence maintenant à l’appliquer pour les systèmes plus classiques grâce à l’avantage indiscutable de l’utilisation d’une norme commune et ainsi mieux comprendre le fonctionnement des systèmes en temps réel — aussi dans leurs interactions — et optimiser leur utilisation. Dans l’univers de production, chaque signal capté par OpenTelemetry permet d’évaluer les performances globales et de prévenir les dysfonctionnements.
L’observabilité avec OpenTelemetry permet également d’identifier les usages réels des applications et des infrastructures. Cela implique de pouvoir calibrer précisément et les éléments des configurations et leurs interactions, que ce soit au niveau des applications ou fonctions elles-mêmes, celui du middleware ou encore sur le niveau des infrastructures. L’objectif est de toujours trouver le juste équilibre entre l’agilité et la résolution proactive des problèmes, avant même que ceux-ci ne deviennent critiques. Bien que les bénéfices d’OpenTe- lemetry soient évidents, son adoption à grande échelle au sein des entreprises IT n’est pas sans défis. En effet, la mise en œuvre de ce framework d’observabilité nécessite une bonne dose d’expertise technique, ainsi que des ressources dédiées pour gérer l’instrumentation et l’analyse des données.
La plupart des logiciels du marché se sont déjà convertis à OTel, comme Splunk, Cisco, et bien d’autres, ce qui en fait d’ores et déjà un standard de fait, même s’il ne fait pas tout et est plutôt adapté aux environnements nativement cloud ou DevOps. ☐
