Qu'est-ce qu'OpenTelemetry ?

Traces

Une trace enregistre les événements qui se produisent pendant une opération telle que le traitement d'une seule demande. La trace est divisée en une série de travées , chacune d'elles représentant une unité de travail .

Par exemple, la trace d’une requête Web peut inclure trois étendues :

• Accepter la demande
• 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 morceaux classés par ordre chronologique pour vous aider à comprendre facilement :

• Toutes les étapes qui se sont déroulées dans chaque partie
• L'ordre dans lequel les morceaux sont exécutés
• Combien de temps a duré chaque étape
• Métadonnées sur chaque étape

Une fois qu’OTel a généré des traces, l’étape suivante consiste à les exporter vers un backend ou un outil de traçage pour analyse. OTel fournit un ensemble d'exportateurs pour les 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.

Métrique

Dans OTel, les métriques sont des mesures d'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étriques ). Les paires clé-valeur fournissent un contexte sur la mesure au fil du temps. Par exemple, une mesure 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. Toutes les mesures sont également horodatées, toujours pour permettre un classement chronologique.

Journaux

Les journaux sont la méthode la plus ancienne et la plus courante pour obtenir un aperçu de ce qui 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 ensembles de fonctionnalités d'observabilité d'OTel à d'autres outils d'observabilité, consultez Intégration d'OpenTelemetry dans l'architecture de référence des applications modernes – Un rapport d'avancement sur notre blog.

OTel s'intègre à de nombreux langages de programmation, bibliothèques et frameworks populaires . Le support dans certaines langues est plus complet que dans d'autres. Par exemple, les bibliothèques d’instrumentation JavaScript ont des implémentations auto-décrites comme « stables » pour le traçage et les métriques et une prise en charge des journaux parmi les plus stables. Ils fournissent également une option d’instrumentation automatique qui vous permet de commencer à recevoir des traces sans ajouter de code spécifique à l’instrumentation à votre logique de service. En revanche, les langages comme Go ont un support moins mature pour les métriques et les journaux et manquent de fonctionnalités d’auto-instrumentation.

Lors de la mise en place d’une instrumentation de télémétrie, il est préférable de commencer par un ensemble d’objectifs d’instrumentation plus définis que « tout envoyer et espérer obtenir des informations ». S’il est vrai que vous ne pouvez pas connaître l’étendue complète de ce qui est possible tant que vous n’avez pas consulté les données, la définition de certaines exigences minimales contribue à garantir le bon fonctionnement et la maintenance de vos services.

Il peut s'agir de problèmes techniques tels que :

• Je veux savoir quand mon service est sous pression et doit être mis à l’échelle.
• Je veux savoir si mon service redémarre souvent.

Mais il peut également 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 les cinq secondes.
• Je souhaite que les notifications soient envoyées dans la minute qui suit l'envoi d'un message.

À titre d’exemple, tiré de notre tutoriel Comment utiliser le traçage OpenTelemetry pour comprendre vos microservices , vous pouvez définir les éléments suivants comme objectifs clés :

• Comprendre toutes les étapes qu’une demande suit pour réaliser le nouveau flux de messages.
• Vérifiez que le flux utilisateur s'est terminé avec succès.
• Soyez sûr que le flux utilisateur s’exécute plus rapidement que cinq secondes d’un bout à l’autre (dans des circonstances « normales »).
• Découvrez si le service de notification traite l'événement (envoyé par le service de messagerie) en temps opportun. 

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.

Étant donné que le format des données produites par OTel est considéré comme une norme industrielle, plusieurs solutions d’agrégation et de visualisation de 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 Software-as-a-Service (SaaS), comme SumoLogic ou SigNoz .

Pour gérer les trois types de télémétrie, la seule alternative à OTel est une combinaison de plusieurs outils. Cela ajoute encore plus de complexité à la complexité inhérente à l’exécution 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 de télémétrie.