Tracing distribué

Où une requête lente passe-t-elle réellement son temps ? Une requête met quatre secondes, mais votre application web semble normale et la base de données est calme. 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 ralentit ou échoue, la cause se trouve souvent dans un service différent de celui qui a montré le symptôme en premier. Le tracing distribué vous permet de suivre cette requête unique à travers ces frontières. AppSignal rassemble le travail de chaque service en une seule trace, afin que vous puissiez voir le trajet complet avant de devoir comparer des horodatages entre applications.

​

Qu’est-ce que le tracing distribué ?

Lorsque chaque service fait son propre rapport, vous pouvez voir 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, ces services peuvent se trouver dans des applications ou des namespaces distincts, si bien que suivre une requête signifie ouvrir chacun d’eux et aligner les horodatages. Le tracing distribué maintient ces services connectés entre eux. 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 span l’a appelé. AppSignal utilise ces données 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 présente une trace distribuée comme 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

Avant d’examiner une requête à travers les services, chaque application doit faire son rapport à un collector hébergé et s’identifier avec un nom de service distinct. Le tracing distribué est disponible via les intégrations AppSignal pour Python, Ruby et PHP, ainsi que via OpenTelemetry pour Go et Java. Elixir et Node.js ne sont pas encore pris en charge. Toute autre application instrumentée avec OpenTelemetry peut également faire son rapport de données de trace à un collector hébergé. Dans le navigateur, AppSignal pour Browser démarre la trace pour les requêtes vers votre API. Ce que vous devez configurer dépend de la façon dont votre intégration envoie des données à AppSignal. Python et Ruby peuvent faire leur rapport soit via leur agent inclus, soit via un collector, vous devez donc activer le mode collector. PHP, Go, Java et les configurations OpenTelemetry personnalisées font déjà leur rapport via un collector, il n’y a donc rien de plus à activer pour le tracing distribué.

• Python : définissez l’option collector_endpoint sur l’URL de votre collector hébergé plutôt qu’auto-hébergé. Consultez configuration du collector pour Python.
• Ruby : définissez l’option collector_endpoint sur l’URL de votre collector hébergé plutôt qu’auto-hébergé. Le mode collector est arrivé avec AppSignal pour Ruby 5.0 et nécessite également le gem appsignal-opentelemetry, à partir de Ruby 3.1 ou une version plus récente. Consultez configuration du collector pour Ruby pour connaître les versions à installer, et tracing distribué pour Ruby pour les bibliothèques qui transportent la trace pour vous.
• PHP : aucun réglage supplémentaire de tracing distribué à activer. 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.
• Go : instrumentez votre application avec le SDK OpenTelemetry et exportez vers l’URL de votre collector hébergé. Enregistrez un propagator avec otel.SetTextMapPropagator, comme le fait le guide d’installation Go. Sans cela, le SDK Go ne propage pas le contexte de trace. AppSignal fournit des instructions de configuration pour les frameworks Gorilla mux et Gin-gonic.
• Java : instrumentez avec le SDK OpenTelemetry ou l’agent Java et exportez vers l’URL de votre collector hébergé. Consultez le guide d’installation Java pour la configuration de l’agent.
• Une configuration OpenTelemetry personnalisée : aucun réglage spécifique à AppSignal pour le tracing distribué à activer. L’export vers un collector hébergé est déjà la façon dont ces configurations font leur rapport, donc les traces se connectent d’elles-mêmes.
• Browser : définissez tracePropagationTargets sur vos hôtes d’API. Chaque requête correspondante porte un en-tête traceparent. Le back-end qui la reçoit a besoin d’une instrumentation de serveur HTTP pour la poursuivre. Une réponse 5xx ou un timeout est signalé comme une erreur de navigateur dans cette trace. Consultez tracing distribué pour Browser.

Définissez également un nom de service pour chaque application. Python, Ruby et PHP le prennent via l’option service_name ou la variable d’environnement APPSIGNAL_SERVICE_NAME ; Go, Java et les configurations OpenTelemetry personnalisées définissent l’attribut de ressource service.name. Définissez-le explicitement pour chaque service. Sans lui, AppSignal ne peut pas distinguer les services d’une trace de façon fiable, et une configuration OpenTelemetry personnalisée s’attend à ce que l’attribut de ressource service.name soit présent. Le tracing distribué repose sur OpenTelemetry, il n’est donc pas limité aux intégrations ci-dessus. Toute application instrumentée avec OpenTelemetry peut faire son rapport de données de tracing distribué à 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. Pour en savoir plus, consultez configuration du collector pour Python, configuration du collector pour Ruby, configuration PHP, configuration Go, configuration Java, et option du nom de service OpenTelemetry.

​

Comment cela fonctionne-t-il dans AppSignal ?

AppSignal construit les traces distribuées sur OpenTelemetry. La partie qui rend cela possible est 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 qu’il a traitée, 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 connectez jamais les services entre eux dans AppSignal à 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. Une fois que les traces commencent à arriver, ouvrez la page de trace pour les examiner 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 chacun à la vue de cette application sur la même trace. Pour suivre une requête à travers une frontière d’application, sélectionnez le service suivant sur la carte. Vous passez d’une application à l’autre le long de la même trace. 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. Une fois que chaque service fait son rapport via un collector hébergé avec son propre nom de service, vous pouvez suivre une requête à travers les services et les applications à partir d’une seule trace.

​

Voir aussi