Traces | OpenTelemetry

The content of this page may be outdated and some links may be invalid. A newer version of this page exists in English.More information ...To see the changes to the English page since this page was last updated: visit GitHub compare bc947371..6bf06ddb9 and search for content/en/docs/concepts/signals/traces.md.
To see the changes to the English page since this page was last updated: visit GitHub compare bc947371..6bf06ddb9 and search for content/en/docs/concepts/signals/traces.md.
Les traces nous donnent une vue d’ensemble de ce qui se passe quand une requête est faite à une application. Que l’application soit monolithique avec une seule base de données ou un maillage de services plus sophistiqué, les traces sont essentielles à la compréhension du “chemin” complet d’une requête dans votre application.
Explorons ceci avec trois unités de travail, représentées par des spans:
Les exemples JSON suivants ne représentent pas un format spécifique, et en particulier pas OTLP/JSON, qui est plus verbeux.
Il s’agit du span racine, décrivant le début et la fin de l’opération entière. On peut noter qu’il possède un champ trace_id indiquant la trace, mais qu’il n’a pas de parent_id. C’est ce qui permet de savoir qu’il s’agit du span racine.
Span hello-greetings :
Ce span encapsule des tâches spécifiques, comme dire bonjour, et son parent est le span hello. On peut noter qu’il partage le même trace_id que le span racine, indiquant qu’il s’agit d’une partie de la même trace. De plus, il a un parent_id qui correspond au span_id du span hello.
Span hello-salutations:
Ce span représente la troisième opération dans cette trace et, comme le précédent, c’est un enfant du span hello. C’est aussi un frère du span hello-greetings.
Ces trois blocs de JSON partagent la même trace_id, et le champ parent_id représente la hiérarchie. C’est ce qui en fait une Trace !
Une autre chose que vous pourrez remarquer, c’est que chaque span a une structure similaire à celle d’un log. C’est parce que c’en est un peu un ! Une manière de comprendre les traces est de les voir comme une collection de logs structurés avec un contexte, une hiérarchie, des corrélations, et bien plus encore. Mais ces logs structurés peuvent provenir de différents processus, services, machines virtuelles, data centers, etc. C’est ça qui permet aux traces de représenter une vue de bout en bout de n’importe quel système.
Pour comprendre comment le traçage fonctionne dans OpenTelemetry, regardons la liste des composants qui vont jouer un rôle dans l’instrumentation de notre code.
Un Tracer Provider (“Fournisseur de traceurs”, parfois appelé TracerProvider) est une usine de Tracer. Dans la plupart des applications, un fournisseur de traceurs est initialisé une seule fois et son cycle de vie correspond au cycle de vie de l’application. L’initialisation du fournisseur de traceurs inclut également l’initialisation de la Ressource et de l’exportateur. il est généralement la première étape dans la mise en place du traçage avec OpenTelemetry. Dans les SDK de certains langages, un fournisseur de traceurs global est déjà initialisé pour vous.
Un Traceur crée des spans contenant des informations à propos des opérations en cours, comme une requête vers un service. Les Traceurs sont créés à partir d’un fournisseur de traceurs.
Les exportateurs de traces envoient les traces à un consommateur. Ce consommateur peut être la sortie standard pour le débogage et le développement, un Collecteur OpenTelemetry, ou n’importe quel backend open source ou d’un éditeur de votre choix.
Le contexte est un des concept fondamentaux qui permet le traçage distribué. Avec le traçage distribué, les spans peuvent être corrélés entre eux et assemblés dans une Trace, quel que soit l’endroit où les spans sont générés. Pour en apprendre plus sur ce sujet, consultez la page Propagation de contexte.
Un span est une unité de travail ou une opération. Les spans sont les blocs de base qui constituent les Traces. Dans OpenTelemetry, ils incluent les informations suivantes:
Les spans peuvent être imbriqués, ce qui est impliqué par la présence d’un ID de span parent: les spans enfants représentent des sous-opérations. Cela permet aux spans de capturer plus précisément les tâches effectuées dans une application.
Le contexte d’un span est un objet immuable contenant les informations suivantes:
Le contexte des spans est la partie du span qui est sérialisé et propagé en même temps que le Contexte Distribué et le bagage.
Puisque le Contexte du span contient l’ID de la Trace, il est utilisé pour créer les Liens de spans.
Les attributs sont des paires clé-valeur qui contiennent des métadonnées que vous pouvez utiliser pour annoter les spans afin de transporter des informations supplémentaires concernant les opérations qu’ils suivent.
Par exemple, si un span suit une opération qui ajoute un article dans le panier d’un utilisateur sur un site d’e-commerce, vous pouvez capturer l’ID de l’utilisateur, l’ID de l’article ajouté au panier et l’ID du panier.
Vous pouvez ajouter des attributs à un span pendant ou après sa création. Privilégiez l’ajout d’attributs à un span lors de sa création afin de rendre l’attribut disponible pour l’échantillonnage du SDK. Si vous devez ajouter une valeur après la création d’un span, mettez à jour le span avec la valeur.
Les attributs sont soumis aux règles suivantes, implémentées par les SDK de chaque langage:
De plus, il existe les Attributs sémantiques, qui sont des conventions de nommages reconnues pour les métadonnées généralement présentes dans les opérations courantes. Il est utile d’utiliser le nommage d’attributs sémantiques dans la mesure du possible afin que les types courants de métadonnées soient standardisés entre les systèmes.
Un Événement de span peut être considéré comme un message de log structuré (ou une annotation) sur un span, généralement utilisé pour signaler un moment particulier, significatif dans la durée de vie du span.
Par exemple, si on considère deux scé