Qu’est-ce que OpenTelemetry ?

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. La trace est divisée en une série de périodes, chacune d’entre elles représentant une unité de travail.

Par exemple, la trace d’une requête web peut comprendre trois travées :

• Acceptation 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 comprendre plusieurs services, en une série de séquences ordonnées chronologiquement afin de faciliter la compréhension :

• de toutes les étapes qui se sont produites dans chaque morceau
• de l’ordre d’exécution des séquences
• de la durée de chaque étape
• des métadonnées sur chaque étape

Une fois que OTel a généré des traces, l’étape suivante consiste à les exporter vers un backend de traçage ou un outil d’analyse. OTel fournit un ensemble d’exportateurs pour des backends populaires tels que Jaeger, Zipkin et AWS X-Ray. Ces services fournissent des outils d’analyse et de visualisation des données de trace.

Indicateurs

Dans OTel, les indicateurs sont des mesures d’aspects spécifiques du comportement d’un système d’exploitation et sont collectés au fil du temps sous forme de paires clé-valeur (appelées étiquettes d’indicateurs). Les paires clé-valeur fournissent le contexte de la mesure au fil du temps. Par exemple, un indicateur pour le 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. Tous les indicateurs sont également horodatés, là encore pour permettre un classement chronologique.

Journaux

Les journaux sont la méthode la plus ancienne et la plus courante pour obtenir des informations sur ce qu’il se passe avec un service donné. Ils sont généralement produits sous forme de texte et doivent être analysés pour générer des informations. La prise en charge des journaux dans OTel est encore expérimentale.

Pour en savoir plus sur ce que nos architectes de solutions ont découvert lorsqu’ils ont comparé les fonctionnalités d’observabilité d’OTel à celles d’autres outils d’observabilité, consultez l’article Integrating OpenTelemetry into the Modern Apps Reference Architecture – A Progress Report sur notre blog.

OTel s’intègre à de nombreux langages de programmation, bibliothèques et frameworks courants. La prise en charge de certains langages est plus complète que d’autres. Par exemple, les bibliothèques d’instrumentation JavaScript ont des implémentations qualifiées de « stables » pour le traçage et les indicateurs, ainsi qu’une prise en charge parmi les plus stables pour les journaux. Elles fournissent également une option d’auto-instrumentation qui vous permet de commencer à recevoir des traces sans ajouter de code spécifique à l’instrumentation à la logique de votre service. En revanche, des langages comme Go ont une prise en charge moins développée pour les indicateurs et les journaux et ne disposent pas de fonctions d’auto-instrumentation.

Lors de la mise en place d’instruments de télémétrie, il est préférable de commencer par définir un ensemble d’objectifs plus précis que « tout envoyer et espérer obtenir des informations ». S’il est vrai que vous ne pouvez pas connaître toute l’étendue des possibilités tant que vous n’avez pas consulté les données, le fait de fixer des exigences minimales permet de garantir le bon fonctionnement et l’entretien de vos services.

Il peut s’agir de questions techniques telles que :

• Comment savoir si mon service est sous pression et s’il a besoin d’être renforcé ?
• Comment savoir si mon service redémarre souvent ?

Mais il peut également s’agir de préoccupations liées au produit et à l’expérience de l’utilisateur, par exemple :

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

Pour reprendre un exemple tiré de notre tutoriel How to Use OpenTelemetry Tracing to Understand Your Microservices, vous pourriez définir les objectifs suivants comme étant les objectifs clés :

• Comprendre toutes les étapes d’une requête pour réaliser le nouveau flux de messages.
• Vérifier que le flux d’utilisateurs s’est déroulé correctement.
• Avoir la certitude que le flux d’utilisateurs s’exécute en moins de cinq secondes d’un bout à l’autre (dans des circonstances « normales »).
• Savoir si le service de notification traite l’événement (envoyé par le service de messagerie) en temps voulu.

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

Le format des données produites par OTel étant considéré comme un standard industriel, de nombreuses solutions d’agrégation et de visualisation de la télémétrie l’acceptent. Vous pouvez choisir une solution sur site, comme Jaeger (comme nous l’avons fait dans ce tutoriel), ou opter pour une solution SaaS (Software-as-a-Service), comme SumoLogic ou SigNoz.

Pour gérer ces trois types de télémétrie, la seule alternative à OTel est de combiner plusieurs outils, ce qui ajoute encore à la complexité inhérente à l’exploitation d’une architecture et d’une infrastructure de microservices.

Les API définissent les méthodes, les fonctions et les protocoles utilisés par les composants logiciels pour interagir entre eux. Les API 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 télémétriques.