OpenTelemetry : instrumentation en .NET dans le futur

Si vous avez développé vos services en .NET C# et que vous avez décidé de déployer vos services sur Azure, vous avez donc évidemment des besoins autour de l’observabilité de vos services, entre autres pour pouvoir faire face aux problèmes à venir en production mais aussi car c’est en contrôlant ce qu’il se passe en production que vous serez en mesure de vous organiser pour améliorer vos services et comprendre / découvrir les usages de vos consommateurs.

Il existe aujourd’hui sur le marché de nombreuses solutions répondant aux besoins. Dans cet article, nous faisons le choix de rester sur l’outil natif Azure Monitor et de discuter de son futur au travers de l’initiative OpenTelemetry.

Monitorer des services .NET

Aujourd’hui, l’écosystème .NET dispose d’outils d’instrumentation matures et de qualité avec Azure Monitor par le biais d’ApplicationInsights.

Par exemple au sein d’une application Asp.Net Core, après avoir déployé votre ressource Azure Monitor et récupéré les éléments de configuration nécessaires, vous installez le paquet Microsoft.ApplicationInsights.AspNetCore, puis vous configurez votre application à l’aide de la clé de configuration ApplicationInsights générée à l’installation de votre ressource Azure Monitor, afin qu’elle dispose des éléments nécessaires pour que les données de télémétrie soit collectées par votre ressource Azure Monitor. Très rapidement, vous pouvez voir ce qui se passe : trafic en temps réel, liste des transactions effectuées…

Pour approfondir le sujet, n’hésitez pas à consulter notre article sur les outils de Run natifs de la plateforme Azure.

ApplicationInsights est une fonctionnalité d’Azure Monitor qui permet de monitorer et de collecter les indicateurs de performance : ces derniers vous permettront d’améliorer les usages de vos services et de débugger les problèmes de production.

Il s’agit d’une solution mature, offrant un ensemble de données télémétriques de façon automatique sans ajout de code supplémentaire : on peut ici évoquer l’intégration avec des utilitaires comme EntityFramework ou le support de la remontée des requêtes/réponses HTTP du célèbre « HttpClient ». Il est également possible d’ajouter ce dont on a besoin. Par exemple, dans un contexte distribué, si vous avez plusieurs instances du même service, vous pouvez ajouter une information qui précise l’instance ayant traité une opération. Nous nous intéressons ici au contexte .NET mais ApplicationInsights supporte d’autres écosystèmes comme Java ou NodeJS.

Ces dernières années, les enjeux de disponibilité et de résilience ont eu pour effet de populariser les architectures distribuées qui entrainent forcément une plus grande complexité à la réalisation mais également aux opérations. Ce sont ces enjeux qui ont popularisé la notion d’observabilité : en effet le monitoring au sens traditionnel part de deux postulats implicites :

• Les équipes d’ingénieurs ont la capacité de pouvoir prédire les indicateurs télémétriques intéressants pour les besoins opérationnels ;
• L’indicateur suffit en lui-même pour pouvoir comprendre la source d’un problème.

Ces deux postulats ne sont plus valables dans un contexte distribué : les interactions entre services sont plus nombreuses aujourd’hui sans même prendre en compte qu’un service même très simple peut interagir avec de multiples magasins de données. Il n’est plus viable, de nos jours, d’attendre une alerte pour savoir qu’il faut intervenir, voire de comprendre où.

Le monitoring classique ne donne pas la capacité de pouvoir déterminer le comportement d’un service. L’observabilité si. Depuis quelques années, les outils existants du marché font évoluer leur offre pour répondre à ce besoin. De nouveaux outils sont également apparus avec l’observabilité comme cœur de leur offre.

De plus, en tant que développeur .NET, il est nécessaire d’intégrer une autre librairie pour pouvoir instrumenter son application ailleurs : en local ou via un autre outil de monitoring. De la même manière, ne pas avoir accès à un niveau de monitoring suffisant, via Azure Monitor, d’un élément d’infrastructure (ce dernier n’étant pas compatible avec ApplicationInsights), pose des problèmes qui viennent s’ajouter aux contextes énoncés plus haut.

En résumé, comment supporter le besoin d’observabilité sur un maximum d’écosystèmes sans dépendance forte entre la solution de collecte d’informations télémétriques et celle de monitoring ?

Cette question est fondamentale aux vues du tournant open source qu’a pris l’écosystème .NET depuis un peu plus de 5 ans. Il est donc important que .NET puisse être aussi bien intégré que NodeJS, Go ou Python vers des outils libres comme Jaeger et Zipkin comme vers des outils commerciaux comme Honeycomb ou Datadog.

Cette question est aussi importante dans le contexte d’Azure Monitor afin de pouvoir offrir le service en posant le minimum de contraintes possible, vis-à-vis de la technologie de développement utilisée.

L’équipe d’Azure Monitor a finalement répondu à cette question, en annonçant sa volonté de rejoindre l’initiative OpenTelemetry. L’écosystème .NET profite également de cette annonce, comme nous le verrons plus tard.

Qu’est-ce que OpenTelemetry ?

OpenTelemetry est un ensemble d’outils, d’APIs et de SDK autour de la collecte et de l’usage d’informations de télémétrie applicative, pour plusieurs écosystèmes (.NET, Elixir, Javascript…).

Le modèle de télémétrie suivant est défini au sein d’une spécification:

• Metrics: utilisées pour prendre la mesure de quelque chose au sein d’un service. Les Metrics vous permettront de connaître le temps de traitement d’une requête ou le taux de latence. Elles sont datées et peuvent également associer des métadonnées, comme l’adresse de l’instance du service d’où provient la mesure ou l’up-time du service par exemple.
• Logs: un log est une information datée de ce qu’il se passe dans votre système. Un log peut être un texte simple ou un événement. Dans le cas d’un évènement, on parle ici de log structuré. On utilise en générale le log pour notifier du changement d’état du système ou d’un événement significatif autre.
• Traces (« Distributed Tracing») : permet le suivi de l’évolution d’une requête au travers de tous les services qui constituent votre système. Dans un contexte de micro-service, grâce à une trace il est possible de suivre le déroulement d’une requête entrante dans votre système et les requêtes enfants qui auront été générées. Il ne nous faut pas confondre cette notion avec celle de « Trace » dans Azure Monitor qui sont en fait des logs.

D’autres éléments sont également définis au travers de cette spécification. Dans le cadre de cet article, les notions suivantes sont particulièrement importantes :

• Librairie d’instrumentation : il s’agit d’une librairie logicielle qui fournit l’instrumentation pour une librairie tierce. Cela permet de pouvoir offrir de l’observabilité de façon plus complète en rendant possible l’observabilité des dépendances que l’on inclut dans son projet.
• Client OpenTelemetry (ou SDK) est la dépendance que l’on inclut dans son application et au travers de laquelle on va pouvoir utiliser le modèle d’OpenTelemetry et mettre en place ses traces, metrics et logs. Il existe un ensemble de SDKs pour une grande variété d’écosystèmes comme .NET, C++ et Python.
• OpenTelemetry Exporter permet de transmettre les données vers un backend spécifique comme Azure Monitor, Jaeger ou Prométheus. Comme les SDKs, il existe pour une grande variété d’écosystèmes.
• OpenTelemetry Collector permet également la collecte et la transmission des données vers un backend spécifique. La différence avec un Exporter est que ce dernier réalise cette opération au travers d’un protocole agnostique (OTLP). Si vous souhaitez ne pas inclure de dépendance vers un backend spécifique dans votre application et/ou utiliser plusieurs backends de monitoring, c’est avec le Collector que vous parviendrez à vos fins. Il propose également deux modes de fonctionnement :
  • Le mode Agent qui est embarqué dans l’applicatif ;
  • Le mode Collector qui est un service propre.

Enfin notons que cette initiative est portée par la très connue « Cloud Native Computing Foundation » (ou CNCF) qui porte entre autres d’autres initiatives comme Kubernetes, Helm ou Prometheus.

Pour résumer : par l’adoption d’OpenTelemetry, Azure Monitor pourra être utilisé avec encore moins d’efforts par un ensemble de technologies plus important. De la même manière, .NET bénéficie d’une intégration vers d’autre plateformes de monitoring, sans coûts supplémentaires.

Azure Monitor, .NET & OpenTelemetry aujourd’hui

Au moment de la rédaction de cet article, Azure Monitor supporte officiellement les traces OpenTelemetry dans les écosystèmes Java, .NET, NodeJS et Python via les « Exporter » s’exécutant au sein des applications cibles. Cependant, il existe des initiatives qui utilisent l’approche via un agent en utilisant « OpenTelemetry Collector ». N’hésitez pas à prendre connaissance de la documentation Microsoft officielle sur le sujet.

Pour le cas plus spécifique de .NET, le support d’OpenTelemetry vers Azure Monitor est assuré par le paquet « Azure.Monitor.OpenTelemetry.Exporter » actuellement encore en bêta. Néanmoins, il faut également noter qu’un ensemble de librairies d’instrumentation de composants clés de .NET et .NET Core sont au stade de release candidate et sont très actives. De même, des « Exporters » vers d’autres plateformes comme Jaeger ou Prometheus sont également en cours de développement.

Il est certes encore un peu trop tôt pour utiliser OpenTelemetry en production dans le contexte .NET ou Azure Monitor, mais pour les projets nécessitant d’être dans l’état de l’art sur les questions d’observabilité, il est fondamental de prendre en compte ce projet et de l’étudier dans une perspective de mise en production au cours de l’année 2022. Pour les autres projets satisfaits par ce qu’ils ont aujourd’hui, il reste quand même important de suivre ce projet car dans un futur très proche, les librairies d’instrumentations et les vendeurs concentreront leurs efforts autour de cette initiative pour toutes les raisons évoquées au sein de cet article.

OpenTelemetry reçoit clairement l’adhésion des éditeurs de solution d’observabilité en plus des grands noms du Cloud public. Ne pas suivre de près les évolutions de ce « nouveau » standard est difficilement justifiable pour les professionnels du logiciel en 2022.

Vous souhaitez en savoir plus sur comment le Build a un impact sur le Run ? Retrouvrez ci-dessous tous les article de cette série proposée en partenariat avec Squadra :

• 12 Factor-App : les patterns à adopter dans le développement d’applications modernes
• Comment maintenir une plateforme Kubernetes en condition opérationnelle ?
• Kubernetes : construire une plateforme en pensant Run
• Les outils de Run natifs de la plateforme Azure
• Run d’un projet IA : garder sous contrôle le cycle de vie d’un modèle ML
• Observabilité des données
• Quels indicateurs pour suivre votre application mobile ?
• Les plateformes d’intégration dans Azure : pourquoi, avec quels axes et comment les monitorer ?