Monitoring : Splunk s’explique sur l’importance d’OpenTelemetry

Vedette lors du dernier événement annuel de Splunk qui se tenait fin juillet aux USA, le système Open source de télémétrie OpenTelemetry figurait aussi parmi les technologies les plus mises en avant en avril dernier lors du salon KubeCON d’Amsterdam. Et pour cause : OpenTelemetry est officiellement devenu le plus ambitieux projet de la CNCF derrière Kubernetes.

C’est d’ailleurs toujours avec des ingrédients d’OpenTelemetry que Cisco compte aujourd’hui détrôner Splunk sur le segment des solutions de monitoring avec sa console universelle FSO. Il n’est pas le seul : nombre d’autres concurrents de Splunk, de New Relic à DynaTrace, en passant par Prometheus, ne jurent plus que par OpenTelemetry.

Né de la fusion des projets Open source OpenTracing et OpenCensus, OpenTelemetry est à la fois un collecteur de métriques sur les clusters Kubernetes, un réceptacle pour les relevés qui proviennent d’autres systèmes et un moteur qui normalise toutes les données qu’il récupère. Il propose un format de données, une API pour injecter et/ou extraire des informations d’observabilité et un kit de développement pour que chaque éditeur intègre ces fonctions dans ses propres produits. 

OpenTelemetry apporte le bénéfice d’une standardisation parmi des logs et des mesures, dont les formats changent d’ordinaire d’un produit à l’autre. Mais, surtout, sa normalisation, faite d’étiquetages, permet de suivre – de tracer – un même événement tout au long de produits informatiques qui n’ont rien à voir entre eux.

Pour comprendre le phénomène OpenTelemetry, LeMagIT est parti à la rencontre de Morgan McLean. Il a cocréé OpenTelemetry vers 2017, alors qu’il travaillait chez Google, et occupe aujourd’hui la fonction de directeur produit chez Splunk pour l’outil d’APM Observability Cloud. Interview.

LeMagIT : De quel besoin est né OpenTelemetry ?

Morgan McLean : Je travaillais à l’époque chez Google sur OpenTracing, qui servait à unifier les relevés de différents « tracers » (Jaeger, LightStep, Datadog, Elastic APM, etc.). Mais cela ne suffisait pas pour avoir une vision globale.

Le problème que nous devions donc résoudre à l’époque est qu’il fallait développer un agent d’observabilité pour chaque environnement applicatif fonctionnant sur GCP. Nous travaillions avec des éditeurs qui nous fournissaient des agents pour leurs frameworks Java ou.Net. Nous leur demandions comment prolonger leurs mesures s’il y avait, par exemple, du code Python ajouté dans la chaîne. Ils nous répondaient qu’ils ne prenaient pas en charge Python. Nous nous sommes dit que cette situation était grotesque.

C’est ainsi que nous sommes partis sur un agent d’observabilité universel qui serait nourri via une API standard par les éditeurs d’environnements applicatifs.

LeMagIT : Ce besoin est celui d’hyperscalers qui veulent monitorer un nombre gigantesque de ressources hétéroclites. En quoi concerne-t-il les entreprises ?

Morgan McLean : Les entreprises sont désormais concernées par ce besoin à cause de Kubernetes. Kubernetes vous permet de construire très simplement des applications web très élastiques et très complexes. C’est-à-dire que vous devez à présent gérer un niveau de complexité que vous ne pouviez pas atteindre auparavant.

La complexité consiste à devoir gérer des milliers de petits services et de fonctionnements très différents. La difficulté est que vous n’avez plus une personne unique qui les maîtrise tous, parce que la console de supervision historique n’est pas assez globale.

Ainsi, si vous embauchez un ingénieur pour implémenter une nouvelle caractéristique dans votre activité, il n’y aura plus personne pour lui indiquer quels sont les cinq ou dix microservices qu’il devra modifier. Et c’est pareil en cas de panne : avec des milliers de microservices en production, il devient très compliqué de savoir lequel a causé une défaillance.

La magie d’OpenTelemetry est qu’il capture toutes les données qui vont vous permettre de prendre une décision. Et il les injecte dans votre solution de monitoring, qu’il s’agisse de Splunk, de Prometheus, de New Relic ou d’autres.

LeMagIT : Si l’on excepte la quantité inédite à récupérer, en quoi ces métriques différeraient-elles de celles que Splunk capture déjà très bien tout seul ?

Morgan McLean : Sans OpenTelemetry, Splunk récupère des logs système et des mesures faites sur les serveurs de production. Ce sont des informations très faciles à obtenir, parce qu’elles sont stockées à un endroit précis de Linux ou de Windows. Avec Kubernetes – mais c’est vrai aussi pour tous les environnements élastiques –, vous avez besoin de tracer les événements d’un module à l’autre.

Vous voulez identifier quand et comment un utilisateur appuie sur un bouton de votre site web, comment cela est traité, comment les APIs sont sollicitées, etc.

Techniquement, vous n’avez plus un produit qui s’interface juste avec Linux et Windows pour lire leurs relevés. Vous avez un produit qui s’interface avec tous les langages de programmation impliqués dans le fonctionnement de vos services, un produit qui suit l’utilisation des bibliothèques de fonction, que ce soit par les langages de programmation, comme par les actions des internautes. Vous avez une infinité de combinaisons possibles.

Avec OpenTelemetry, Splunk peut par exemple vous montrer la présence de vos clients, vous pouvez savoir ce qui se passe sur votre application d’e-commerce, Splunk peut vous montrer ce qui prend du temps, quelle est la latence d’Internet, quelle est la latence de votre service back-end, etc. Vous pouvez voir quel container impacte quel microservice, quel microservice impacte quelle transaction, ou faire le chemin inverse.

LeMagIT : On comprend surtout qu’OpenTelemetry est le moteur qui a permis à Splunk de proposer à son tour une console d’APM, Splunk Observability Cloud. Mais en quoi OpenTelemetry rend-il Splunk Observability Cloud meilleur qu’une autre solution d’APM ?

Morgan McLean : La beauté d’OpenTelemetry, par rapport à d’autres traceurs classiques, est qu’il sait tout intégrer et qu’il s’assure que tous les relevés sont consistants.

Un même événement sera annoté de la même manière et aura la même structure dans les relevés qui viennent d’un service en Python, dans ceux qui viennent d’un autre service en Java, dans les mesures d’une bande passante. De sorte que, quand vous analysez ces données sur un tableau de bord, une seule requête peut fonctionner sur toutes les métriques, toutes les traces, tous les logs qui remontent des services, quelle que soit la technologie de ces services. Vous trouvez la première cause d’un événement plus rapidement.

Du point de vue des entreprises, l’avantage d’OpenTelemetry est qu’elles n’ont plus à déployer sur chacune de leurs ressources des agents d’observabilité fournis par telle ou telle solution de monitoring, d’autant que les solutions de monitoring n’ont pas forcément des agents d’observabilité pour tous les frameworks.

Il y a dans OpenTelemetry un travail d’intégration énorme, qui serait impossible à faire pour un seul éditeur, qu’il s’appelle Splunk, Dynatrace, ou autre. OpenTelemetry étant le second plus gros projet de la CNCF, il bénéficie d’une popularité qui incite tous les éditeurs de frameworks, de bases de données, de services web ou même d’apps clients, à faire l’effort d’intégrer leur solution à OpenTelemetry, via son protocole, son API.

Après, pour être tout à fait honnête, tout n’est pas encore compatible avec OpenTelemetry. À date, l’essentiel des technologies autour de Kubernetes est bien supporté. En revanche, il manque encore le support des apps.

LeMagIT : Doit-on craindre une mainmise de Splunk sur OpenTelemetry ?

Morgan McLean : Absolument pas. OpenTelemetry est un projet Open source. Certes, Splunk est aujourd’hui le plus gros contributeur, mais il y en a d’autres : Microsoft, Dynatrace…

Ce que je peux vous dire à ce sujet, néanmoins, est que Splunk intègre dans Observability Cloud une version étendue d’OpenTelemetry, qui comprend le profiling des données. Cette fonction n’est pas encore implémentée dans l’OpenTelemetry standard, car la communauté doit encore se réunir, débattre, voter pour son intégration. Chez Splunk, nous avons néanmoins considéré que cette fonction ne pouvait pas attendre.

LeMagIT : Doit-on comprendre qu’OpenTelemetry ne sert, chez Splunk, qu’à faire de l’APM ?

Morgan McLean : Pour l’instant, OpenTelemetry est juste un composant d’Observability Cloud. Cependant, toutes les informations qu’il remonte sont déjà agrégées dans la base de données globale Splunk, laquelle alimente aussi bien nos consoles pour la maintenance de l’IT que notre SIEM et nos consoles de cybersécurité.

« Demain, toutes les consoles Splunk prendront nativement en compte OpenTelemetry, la structure de ses données et le fonctionnement de ses requêtes. »

Au-delà de l’APM, OpenTelemetry fournit donc aux outils Splunk des métriques pour montrer ce qui se passe dans les clusters Kubernetes. Elles sont utilisables dans une certaine mesure pour dépanner des serveurs, des réseaux, mais nous reconnaissons qu’il manque encore des mécanismes pour relier ces informations aux risques de cybersécurité.

Techniquement, par exemple, nos consoles se mettent à jour en envoyant de nouvelles requêtes à chaque fois. Alors que, dans la conception d’OpenTelemetry, un événement est un objet qui se met à jour tout seul avec une seule requête au départ.

Demain, toutes les consoles Splunk prendront nativement en compte OpenTelemetry, la structure de ses données et le fonctionnement de ses requêtes. Et il deviendra dès lors possible de retracer directement le parcours d’une attaque ou d’un problème nés d’une faille dans le fonctionnement de Kubernetes ou de toute autre ressource compatible avec OpenTelemetry.