De plus en plus d’entreprises cherchent à moderniser leurs applications ‘maison’, notamment celles qu’elles considèrent comme différenciantes et génératrices de valeur, et se tournent vers les micro-services. En s’orientant vers ce type d’architecture orientée services, elles facilitent la mise à jour de certaines parties sans devoir tout déployer.

Cela étant dit, dans une application de micro-services, le suivi du bon déroulement des opérations doit se faire dans plusieurs dizaines, voire plusieurs centaines de services.

L’un des défis majeurs que pose le développement de micro-services est donc la capacité à tracer l’opération d’un client à travers tous les services impliqués dans le traitement.

A mesure que les applications grandissent, le test et la surveillance logiciels sont essentiels pour garantir la qualité du code et du service fourni. Le traçage facilite le débogage, l’analyse des performances, les tests A/B et d’autres diagnostics standards

Ce mouvement vers des applications plus modernes s’accompagne à la fois d’une complexité, d’une augmentation des dépendances et d’un volume de données conséquent mais aussi d’une fréquence et d’une accélération des cycles de développement.

Pour mieux appréhender la complexité des architectures et la fréquence accrue des déploiements logiciels, l’observabilité entre en jeu.

L’observabilité est un véritable enjeu puisqu’elle collecte des données de télémétrie de l’infrastructure, des machines virtuelles et des containers, des clusters Kubernetes, du middleware et du logiciel, dans le cloud ou non, en mode PaaS ou non, pour faciliter la supervision et la compréhension de l’analyse des données. Elle collecte aussi les données de télémétrie à partir du browser ou de l’application pour appréhender l’expérience utilisateur, incluant des événements et des attributs métier pour mieux comprendre les liens entre performance applicative et besoin métier.

OpenTelemetry a donc vu le jour en 2019, initiative lancée par différents contributeurs (et notamment la fusion d’OpenTracing et d’OpenCensus), OpenTelemetry est Open source, donc utilisable par tout le monde

• Les développeurs peuvent utiliser les librairies d’OpenTelemetry pour instrumenter leur code, collecter des métriques et des traces, et suivre les performances de leurs applications à travers tous les environnements de déploiement, y compris le Cloud et, bien évidemment, les conteneurs
• Les équipes d’exploitation (OPS) peuvent utiliser les outils OpenTelemetry pour visualiser et analyser ces données.

OpenTelemetry permet de bénéficier d’une plateforme d’observabilité unifiée pour le développement et la maintenance de leurs applications, directement liée à leurs cycles CI/CD. Il est également possible d’utiliser des services de monitoring qui utilisent OpenTelemetry pour visualiser les données de manière simple.

Pour toutes ces raisons, OpenTelemetry connait un grand engouement et est devenu, en quelque sorte, incontournable dans le domaine de la surveillance des performances d’une application bien qu’il n’en soit encore qu’à ses débuts.

Les avantages d’OpenTelemetry

Les principaux avantages, mis ensemble, en font un outil assez bluffant :

Tout-en-un : prend en charge toutes les étapes du processus de télémétrie pour ne pas avoir besoin d’utiliser des outils tiers et permet de capturer les données de télémétrie et de les transmettre à un back-end sans changer l’instrumentation.

Un choix plus simple : plus besoin de choisir entre OpenTracing et OpenCensus, vous bénéficiez des avantages de l’une et de l’autre dans une même solution, et cerise sur le gâteau, OpenTelemetry est rétro compatible

Universel : adapté à tous les langages et tous les backends.

Infiniment personnalisable : vous pouvez l’adapter pour absolument tous les besoins.

OpenTelemetry améliore l’observabilité en rassemblant les traces, les logs et les métriques de l’ensemble des applications et services en les corrélant. En consolidant les différentes données de télémétrie, OpenTelemetry est en mesure de :

• Vérifier que les systèmes fonctionnent correctement
• Déceler les éventuels problèmes de performance, les comprendre et corriger les causes

Et ainsi, prévenir une potentielle interruption de service.

De plus, OpenTelemetry est open source, totalement gratuit, et relativement simple à utiliser.

Les inconvénients d’OpenTelemetry

Le passage à OpenTelemetry est, généralement, à l’initiative de l’équipe de développement. Par conséquent, il n’est pas rare que les Ops subissent cette adoption, notamment s’ils n’ont pas une compréhension de la technologie, de ce qu’elle apporte et de la manière dont elle s’intègre dans leur système de surveillance.

OpenTelemetry collecte des données isolées, mais ne fournit pas une vue complète des performances. En d’autres termes, il ne s’intéresse qu’à la génération de données ; ce qui n’aide pas les équipes informatiques à comprendre les grands volumes de données créées. Il faut donc que ces données soient transformées en informations compréhensibles à l’aide d’outils.

En effet, OpenTelemetry génère un volume important de données, notamment des traces et des métriques, qui nécessitent un effort de projection pour avoir une vision d’ensemble de l’application. Le niveau de visibilité est effectivement très différent de celui obtenu via un agent propriétaire dans les environnement On Premise.

Utilisé seul, il est difficile d’en tirer une valeur substantielle.

C’est la que peut intervenir l’IA ?

OpenTelemetry peut injecter les données collectées dans un moteur d’IA pour produire automatiquement des informations exploitables :

• traiter des milliards de dépendances au sein d’un système distribué en quelques fractions de seconde,
• apprendre ce qu’est l’état normal et par voie de conséquence ce qui ne l’est pas
• identifier automatiquement la source des problèmes et les résoudre avant qu’ils n’affectent les utilisateurs finaux.

Pour synthétiser, l’intégration de l’IA augmente la valeur d’OpenTelemetry en réduisant l’effort manuel nécessaire pour analyser les données dans un processus continu.

Il existe par ailleurs de nombreux outils et services qui sont Open source et compatibles avec OpenTelemetry et notamment :

Prometheus : un système de surveillance de performances qui peut collecter et stocker des données de métriques à partir d’OpenTelemetry.

Grafana : un outil de visualisation de données qui peut utiliser des données collectées par OpenTelemetry pour créer des graphiques et des tableaux de bord.

Jaeger : un outil pour la surveillance des traces qui peut collecter et afficher des données de traces à partir d’OpenTelemetry.

Zipkin : un autre outil pour la surveillance des traces qui peut collecter et afficher des données de traces à partir d’OpenTelemetry.

Elasticsearch, Logstash and Kibana (ELK) : une plateforme pour la gestion des données de journal qui peut collecter et stocker des données de traces à partir d’OpenTelemetry

De la théorie à la pratique

Même si le cloud apparait comme étant l’avenir de l’informatique, la migration vers le cloud reste très compliquée, et on peut penser que l’abandon des applications et des infrastructures on-premise se fera progressivement.

Dans cette phase transitoire,

• Les équipes IT ont besoin d’une plateforme pour à la fois observer les environnements cloud native et on-premise.
• Les responsables IT ont besoin de corréler les données informatiques avec les indicateurs business pour donner du sens à leurs actions.

En d’autres termes, les équipes informatiques ont besoin d’une plateforme d’observabilité capable d’extraire les transactions business (ou métiers) des données d’OpenTelemetry ainsi que d’autres éléments de données MELT (metrics, events, logging, and tracing), pour l’infrastructure, l’application et les données enregistrées par le fournisseur de cloud.

C’est pourquoi il est essentiel que les équipes IT puissent intégrer l’OpenTelemetry directement dans leur plateforme d’observabilité unifiée, afin

• d’obtenir une vue claire sur l’ensemble du parcours de l’application,
• de minimiser les opérations manuelles,

pour optimiser le temps moyen de résolution (MTTR) et le temps moyen de survenance (MTTX), même lorsque les composants s’exécutent dans des environnements on-premise et cloud native.

Concrètement, comment ça fonctionne ?

OpenTelemetry se compose de trois grands éléments :

Spécifications : protocoles standards ouverts qui constituent la base d’OpenTelemetry, incluant les exigences de mise en œuvre.

Bibliothèques d’instrumentation : bibliothèques spécifiques à un langage pour implémenter OpenTelemetry , instrumenter les applications et générer les données à envoyer au collecteur OpenTelemetry.

Collecteur : reçoit, traite et transmet les données aux back-ends d’observabilité choisis.

Au niveau supérieur, OpenTelemetry se compose de trois éléments principaux :

Un ensemble d’API pour instrumenter des applications, des bibliothèques et des frameworks. L’API comporte quatre sections principales : le traçage et notamment le traçage distribué, les compteurs, un contexte partagé et les conventions sémantiques

Le SDK qui implémente les API. Une API, pour Application Programming Interface, est un programme permettant à deux applications distinctes de communiquer entre elles et d’échanger des données

Un collecteur pour ingérer, agréger et exporter des données de télémétrie partout où vous en avez besoin.

Pour démarrer avec OpenTelemetry Azure monitor pour des applications NodeJS : https://learn.microsoft.com/fr-fr/azure/azure-monitor/app/opentelemetry-nodejs-exporter

En conclusion

OpenTelemetry est un outil incontournable pour simplifier la génération d’alertes et le débogage des applications. Si les données de télémétrie ont toujours existé, la complexité des applications a rendu leurs collectes et leurs analyses plus difficiles. Dans ces systèmes devenus de véritables labyrinthes, tracer la cause d’un incident à l’aide de méthodes traditionnelles peut prendre des heures voire des jours.

Peu d’entreprises l’ont mis en œuvre dans leurs environnements Cloud native, en revanche, la situation évolue très rapidement. Il est quasiment impossible désormais de trouver une entreprise qui ne mentionne pas OpenTelemetry dans sa stratégie d’observabilité à moyen/long terme.