Qu’est-ce qu’OpenTelemetry ?

OpenTelemetry (OTel) est un projet open source qui fournit une norme indépendante des fournisseurs pour collecter, traiter et exporter les données de télémétrie issues de systèmes distribués (tels qu’une architecture de microservices). Cette approche simplifiée et universelle de l’observabilité permet aux développeurs d’analyser plus facilement les performances et le comportement des logiciels, afin de diagnostiquer et de corriger plus aisément les problèmes dans leurs applications. OTel collecte les données suivantes :

Traces – « Où se situe le problème ? »
Métriques – « Y a-t-il un problème ? »
Journaux – « Quel est le problème ? »

OTel n’est ni un langage de programmation ni un produit. Ce projet open source existe depuis 2019 et est actuellement géré par la Cloud Native Computing Foundation (CNCF).

Regardez cette vidéo pour savoir comment démarrer :

Types de données générées par OTel

Traces

Une trace enregistre les événements qui se produisent au cours d’une opération, telle que le traitement d’une requête unique. Elle est divisée en une série de segments, chacun représentant une unité de travail.

Par exemple, la trace d’une requête web peut comporter trois segments :

Réception de la requête
Interrogation de la base de données
Envoi d’une réponse

Une trace découpe un flux de données, qui peut inclure plusieurs services, en une série de segments classés par ordre chronologique afin de vous aider à comprendre facilement :

Toutes les étapes qui se sont déroulées dans chaque segment
L’ordre dans lequel les blocs ont été exécutés
La durée de chaque étape
Métadonnées relatives à chaque étape

Une fois qu’OTel a généré les traces, l’étape suivante consiste à les exporter vers un système de traçage ou un outil afin de les analyser. OTel propose un ensemble d’exportateurs pour des systèmes populaires tels que Jaeger, Zipkin et AWS X‑Ray. Ces services fournissent des outils permettant d’analyser et de visualiser les données de traçage.

Métriques

Dans OTel, les métriques mesurent des aspects spécifiques du comportement d’un système d’exploitation et sont collectées au fil du temps sous forme de paires clé-valeur (appelées étiquettes de métrique). Les paires clé-valeur fournissent des informations contextuelles sur la mesure au fil du temps. Par exemple, une métrique relative au temps de réponse d’un service web peut inclure des étiquettes pour le code d’état HTTP, le point de terminaison et la méthode HTTP. Toutes les métriques sont également horodatées afin de permettre leur classement chronologique.

Journaux

Les journaux constituent la méthode la plus ancienne et la plus courante pour comprendre ce qui se passe au sein d’un service donné. Ils sont généralement produits sous forme de texte et doivent être analysés pour en tirer des informations utiles. La prise en charge des journaux dans OTel est encore expérimentale.

Pour en savoir plus sur les conclusions de nos architectes de solutions après avoir comparé les fonctionnalités d’observabilité d’OTel à celles d’autres outils d’observabilité, consultez l’article Intégration d’OpenTelemetry à l’architecture de référence des applications modernes – Rapport d’avancement sur notre blog.

Instrumentation OTel

OTel s’intègre à de nombreux langages de programmation populaires, bibliothèques et frameworks. La prise en charge est plus complète dans certains langages que dans d’autres. Par exemple, les bibliothèques d’instrumentation JavaScript proposent des implémentations qu’elles qualifient de « stables » pour le traçage et les métriques, ainsi qu’une prise en charge des journaux parmi les plus stables. Elles offrent également une option d’auto-instrumentation qui permet de commencer à recevoir des traces sans ajouter de code propre à l’instrumentation à la logique de votre service. En revanche, des langages comme Go offrent une prise en charge moins mature des métriques et des journaux et ne disposent pas de fonctionnalités d’auto-instrumentation.

Objectifs de télémétrie

Lors de la mise en place de l’instrumentation de télémétrie, il est préférable de commencer par définir des objectifs plus précis que « tout envoyer et espérer en tirer des enseignements ». S’il est vrai que vous ne pouvez pas connaître toute l’étendue des possibilités avant d’avoir examiné les données, la définition de quelques exigences minimales contribue à garantir le bon fonctionnement et la maintenance de vos services.

Il peut s’agir de considérations techniques telles que :

Je veux savoir quand mon service est soumis à une forte charge et doit être mis à l’échelle.
Je veux savoir si mon service redémarre souvent.

Mais il peut aussi s’agir de préoccupations liées au produit et à l’expérience utilisateur, telles que :

Je veux que les utilisateurs voient les nouveaux messages dans le système dans un délai de cinq secondes.
Je veux que les notifications soient envoyées dans la minute suivant l’envoi d’un message.

À titre d’exemple, dans notre tutoriel « Comment utiliser le traçage OpenTelemetry pour comprendre vos microservices », vous pourriez définir les objectifs clés suivants :

Comprendre toutes les étapes suivies par une requête pour exécuter le nouveau flux de messages.
Vérifiez que le parcours utilisateur s’est terminé correctement.
Assurez-vous que le parcours utilisateur s’exécute de bout en bout en moins de cinq secondes (dans des conditions « normales »).
Déterminer si le service de notification traite l’événement (envoyé par le service de messagerie) dans les délais impartis.

Implémentation d’OTel

OTel fournit aux développeurs un ensemble unique d’interfaces de programmation d’applications (API), de kits de développement logiciel (SDK) et de bibliothèques d’instrumentation qu’ils peuvent utiliser pour instrumenter leurs applications de manière cohérente et standardisée.

Le format des données produites par OTel étant considéré comme une norme du secteur, de nombreuses solutions d’agrégation et de visualisation des données de télémétrie le prennent en charge. Vous pouvez choisir une solution sur site, comme Jaeger (ainsi que nous l’avons fait dans ce tutoriel), ou opter pour une solution Software-as-a-Service (SaaS), comme SumoLogic ou SigNoz.

Pour gérer les trois types de télémétrie, la seule alternative à OTel consiste à combiner plusieurs outils. Cela ajoute encore davantage de complexité à celle déjà inhérente à l’exploitation d’une architecture et d’une infrastructure de microservices.

Qu’est-ce qu’une API dans le contexte d’OTel ?

Les API définissent les méthodes, les fonctions et les protocoles utilisés par les composants logiciels pour interagir entre eux. Les API d’OTel définissent un ensemble standard de méthodes et de protocoles que les développeurs peuvent utiliser pour instrumenter leurs applications et collecter des données de télémétrie.

Qu’est-ce qu’un SDK dans le contexte d’OTel ?

Les SDK sont des outils de développement logiciel fournis par l’auteur d’une norme ou d’une application afin d’aider les développeurs à créer des applications conformes à cette norme ou capables d’interagir avec cette application. Ils comprennent généralement des bibliothèques, des exemples de code, de la documentation ainsi que des outils de test, de débogage et d’optimisation des performances. OTel fournit des SDK pour le traçage, les métriques et la gestion des ressources.

Contenu associé