Tracing distribué

Où une requête lente passe-t-elle réellement son temps ? Le temps de réponse de votre application web semble normal, la base de données est calme, et la requête met tout de même quatre secondes. Une seule requête peut s’authentifier auprès d’un service, charger des données depuis une API interne, mettre en file d’attente une tâche en arrière-plan et appeler l’API de paiement d’un tiers avant que la réponse ne revienne. Lorsqu’elle est lente ou échoue, la cause se trouve souvent dans un service différent de celui qui a signalé le problème. Le tracing distribué suit cette requête lorsqu’elle traverse ces frontières et rassemble le travail de chaque service sous une seule trace, afin que vous voyiez le trajet complet au lieu de le reconstituer service par service. Pensez à une conversation de groupe : chaque service répond dans le même fil, si bien que la requête se lit comme une seule conversation au lieu de cinq échanges séparés.

​

Qu’est-ce que le tracing distribué ?

Lorsque chaque service fait son propre rapport, vous voyez qu’une action web est lente, mais pas qu’un service d’inventaire plus loin dans la chaîne d’appels en est la cause. Dans AppSignal, chacun de ces services est une application ou un namespace distinct. Pour suivre une requête à travers eux, vous devez ouvrir chacun d’eux et aligner les horodatages. Le tracing distribué supprime ces frontières. Lorsqu’une requête passe d’un service au suivant, chaque service marque son travail avec le même identifiant de trace et enregistre quel travail l’a appelé. AppSignal utilise ces identifiants pour reconstituer le trajet complet de la requête, à travers chaque service qui y a pris part. Avec une trace distribuée, vous pouvez :

• Suivre une requête depuis son point d’entrée jusqu’à chaque service atteint.
• Voir où le temps a été passé, même lorsque la partie lente s’exécute dans un autre service ou une autre application.
• Trouver dans quel service une erreur a commencé, pas seulement où elle est apparue.

​

Spans, traces et services

AppSignal décrit une trace à l’aide de trois éléments de base.

• Span : une unité de travail unique, comme une requête HTTP entrante, une requête de base de données, un appel vers un autre service, ou un bloc de code que vous instrumentez vous-même. Un span a un nom, une durée et des attributs, et il enregistre le span qui l’a démarré. Les spans sont le plus petit élément dont une trace est composée.
• Trace : tous les spans qui appartiennent à une opération de bout en bout. Comme chaque span connaît son span parent, les spans d’une trace forment un arbre qui décrit la requête du début à la fin.
• Service : un composant nommé qui prend part à une trace, comme une application web, un worker en arrière-plan ou une API interne. Vous nommez un service avec l’option service_name (ou la variable d’environnement APPSIGNAL_SERVICE_NAME), et AppSignal utilise ce nom pour distinguer les services au sein d’une trace. Une seule trace traverse généralement plusieurs services, et ces services peuvent faire leur rapport à différentes applications AppSignal.

Au sein d’AppSignal, une trace est une sorte d’ échantillon : l’enregistrement détaillé d’une requête, stocké afin que vous puissiez l’ouvrir et le lire span par span. AppSignal calcule vos métriques de performance, comme le temps de réponse et le throughput, à partir de ces traces, si bien qu’un graphique de performance et une trace individuelle sont deux vues des mêmes données.

​

Disponibilité et configuration

Le tracing distribué est d’abord disponible pour Python, Ruby et PHP. Les autres langages, comme Elixir et JavaScript, ne sont pas encore pris en charge. Le fait de devoir activer quelque chose dépend de la façon dont votre intégration fait son rapport à AppSignal. Python et Ruby peuvent faire leur rapport soit via l’agent inclus dans l’intégration, soit via un collector, il faut donc configurer le mode collector. PHP et une configuration OpenTelemetry personnalisée ne font jamais leur rapport que via un collector, il n’y a donc rien à activer.

• Python et Ruby : définissez l’option collector_endpoint sur l’URL d’un collector hébergé plutôt qu’auto-hébergé. Consultez configuration du collector pour Python, configuration du collector pour Ruby, et collectors hébergés ou auto-hébergés pour connaître la différence entre les deux.
• PHP : rien à configurer. Le package PHP fait déjà son rapport via un collector, donc le tracing distribué fonctionne dès que votre application fait son rapport à AppSignal.
• Une configuration OpenTelemetry personnalisée : rien à configurer. L’export vers un collector est le seul moyen dont ces configurations font leur rapport, donc les traces se connectent d’elles-mêmes.

Le tracing distribué repose sur OpenTelemetry, il n’est donc pas limité aux intégrations ci-dessus. Toute application instrumentée avec OpenTelemetry peut rejoindre une trace en exportant ses données vers un collector hébergé. Vous pouvez le faire via une intégration AppSignal comme le package PHP, ou via une configuration de SDK OpenTelemetry personnalisée.

​

Comment cela fonctionne-t-il dans AppSignal ?

AppSignal construit les traces distribuées sur OpenTelemetry, qui prend en charge la partie qui rend le tracing distribué possible : la propagation du contexte. Lorsqu’un service instrumenté appelle un autre service, OpenTelemetry attache l’identifiant de trace et le span appelant à l’appel sortant. Il voyage sous forme d’en-têtes sur une requête HTTP, ou de métadonnées sur une tâche mise en file d’attente, et le service qui le reçoit le lit et poursuit la même trace. Chaque service fait son rapport sur la portion de la trace dont il est responsable, appelée sa sous-trace. AppSignal reçoit ces sous-traces indépendamment, souvent depuis des processus ou des hôtes différents, et les réassemble en une seule trace à l’aide de l’identifiant de trace partagé et des liens parent-enfant entre les spans. Vous ne configurez jamais la connexion entre les services à la main. Si une bibliothèque est instrumentée, ses appels rejoignent la trace automatiquement. AppSignal échantillonne les traces plutôt que de toutes les conserver, et prend cette décision à l’échelle des services : lorsqu’une trace est conservée, le travail de chaque service qu’elle contient l’est aussi, si bien que la trace arrive complète au lieu d’arriver en fragments épars. Le sampling privilégie les traces que vous voulez le plus voir, celles avec des erreurs et les requêtes les plus lentes. Des lacunes peuvent tout de même apparaître aux extrémités, lorsqu’un service ne fait pas son rapport ou que ses données arrivent trop tard. Vous explorez le résultat sur la page de trace de deux façons : la carte des services, qui montre les services de la trace et les appels entre eux, et la chronologie de trace, qui dispose chaque span dans le temps. La page de trace explique comment lire les deux.

​

Prise en charge inter-applications

Un service dans AppSignal n’est pas la même chose qu’une application. Plusieurs services peuvent faire leur rapport à une seule application AppSignal, et une trace unique peut aussi traverser des services appartenant à des applications entièrement distinctes. Par exemple, une application web, un service d’inventaire et un service d’audit peuvent tous faire leur rapport à une même application AppSignal, chacun sous son propre nom de service, tandis qu’un service séparé fait son rapport en tant qu’application distincte. Une seule action utilisateur, comme un checkout, peut produire une trace qui inclut des services des deux applications. La carte des services d’AppSignal traite cela comme une seule trace, quel que soit l’endroit où chaque sous-trace a été rapportée. Elle détermine l’application à laquelle appartient chaque service et relie chaque carte à la vue de cette application sur la même trace. Pour suivre une requête à travers une frontière d’application, sélectionnez la carte du service suivant. Vous passez d’une application à l’autre le long de la même trace, sans perdre le fil. Cela fonctionne parce que le contexte se propage à travers les frontières de processus et d’application de la même manière qu’entre les services, et qu’AppSignal fait correspondre les sous-traces par leur identifiant de trace partagé, et non par l’application ou l’hôte d’où elles proviennent.

​

Voir aussi