Dans les SI modernes, on parle de plus en plus de micro-services. Des applications métier, valeur publique de l’entreprise, aux applications techniques à usage interne, en passant aujourd’hui même par les éléments composants le SI lui-même, comme par exemple les différents éléments d’un cluster Kubernetes, toutes les applications tendent à se développer ou migrer vers ce type d’architectures.

On ne rentrera pas aujourd’hui sur le pourquoi du comment des micro-services, le détail de leurs avantages ou leurs inconvénients, mais sur un de leurs inconvénients majeurs : la traçabilité.

On l’a dit et répété, une application n’est pas totalement terminée tant qu’elle n’est pas observable, si l’on n’a pas la possibilité de voir, comprendre, analyser et potentiellement anticiper ses erreurs, ce qui passe par la remontée de traces d’erreur ; de métriques, permettant de suivre le fonctionnement de l’application ; et de logs, à des fins d’analyse dans le cas où des erreurs plus “fonctionnelles” arriveraient, mais également dans le cas où votre plateforme serait victime d’une attaque, d’un dysfonctionnement technique et j’en passe.

Je précise que je parle bien ici de monitorer des systèmes distribués, et non des applications monolithiques, pour lesquelles des milliers d’outils et de protocoles déjà bien établis existent. Les implications sont multiples, instrumenter un système distribué est un challenge car la possibilité de tracer par exemple un appel d’API qui partirait d’un front, passerait par une API Gateway pour ensuite être redirigée sur un backend, qui pourrait à son tour en appeler d’autres, pour en bout de chaine appeler une base de données, tout cela est un processus complexe et une erreur peut vite survenir à n’importe quelle étape de ce processus, d’où l’importance encore plus importante de correctement implémenter l’observabilité de ces systèmes.

Beaucoup de solutions existent aujourd’hui permettant de mettre en place ce genre d’instrumentation. Des applications et solutions, certaines open-source, d’autres, plus orientées vers de grosse entreprise et souvent très chères pour pas toujours grand-chose, certaines ne communiquant que dans leur propre protocole et d’autres plus ouvertes permettant de faire à peu près ce que l’on veut.

Je vous parle depuis tout à l’heure de solutions clés en main permettant d’ajouter cette couche d’observabilité, cependant ce n’est pas de ces outils que je souhaite vous parler aujourd’hui, mais bien de la manière d’instrumenter, donc de ce qui se retrouvera réellement dans votre projet, permettant le résultat escompté.

Le principe est toujours plus ou moins le même, votre projet génère des données, dans un format, qu’il enverra à un collecteur, qui l’enverra à son tour, en passant ou pas par un autre processus, vers une base de données qui vous permettra ensuite de consulter ces données de manière centralisée.

Comme je le disais plus tôt, la problématique que je vois aux solutions existantes est que beaucoup implémentent leurs propres protocoles, leur propre manière qu’auront vos applications de communiquer avec elles, et même si beaucoup proposent un catalogue impressionnant de librairies clé en main pour beaucoup des langages les plus populaires, ce n’est pas le cas de toutes, et s’engager dans du développement pour intégrer un outil propriétaire ou presque ne s’avère pas souvent être une bonne pratique à long terme….

OpenTelemetry

OpenTelemetry se définit comme un “ensemble d’outils, d’APIs et de SDK permettant d’instrumenter, de générer, collecter et exporter des données de télémétrie sur nos applications, dans le but de nous aider à analyser ses performances et le comportement” (extrait de opentelemetry.io).

En clair et pour tous, OpenTelemetry (ou OTel pour les intimes, et surtout pas OT) passe avant tout par une spécification, un langage permettant de définir la manière d’instrumenter notre application (métriques, logs et traces), dans le but de permettre à toutes nos applications, quelles qu’elles soient, et quelles que soit les technologies qu’elles emploient, d’exporter ces données en suivant les mêmes règles ; ainsi que de fournir des librairies permettant l’implémentation de ces règles dans tous les langages et les technologies modernes.

Le but final derrière tout cela est de permettre à des outils d’analyse et de visualisation, venant bien après tout le process d’instrumentation, l’exploitation de données unifiées à travers toutes les applications, mais surtout, puisque nous parlons ici encore une fois de services distribués, toutes les couches composant notre application complète.

De par sa communauté très active, et que le projet n’est pas backé par moins que la CNCF elle-même, le projet plaira par sa documentation très explicite et sa facilité à être implémenté sur des nouveaux projets comme sur des projets existants, ainsi que par son évolution rapide.

Visualisation

Attention cependant à un point important : OpenTelemetry n’est pas en soi une solution complète de télémétrie pour vos applications, son champ d’action s’arrêtant à la collecte des données de votre application et l’envoi à un backend, à part, qui s’occupera de les traiter.

Une palanquée d’outils géniaux, open-source ou enterprise permettent dès aujourd’hui l’analyse des formats de données OpenTelemetry, dont de très gros projets comme Jaeger, Zipkin et Prometheus, probablement déjà déployés dans votre SI !

Conclusion

OpenTelemetry n’est pas en soi un outil ayant pour but de révolutionner l’instrumentation de code, mais simplement de permettre l’instrumentation de tous les codes avec un protocole ouvert, open-source et cloud-friendly, leur documentation est extrêmement agréable à lire et en tant que féru membre de la CNCF, je n’aurai qu’une chose à vous conseiller, essayez !

©️ Julien PONTILLO | Consultant KLANIK