Concepts de traçage

Une pile d'appels est une liste ordonnée d'exécutions de code. Chaque fois que le code appelle un autre code, le nouveau code est placé dans la partie supérieure de la pile. Les piles d'appels sont utilisées par les environnements d'exécution de tous les langages de programmation et sont généralement imprimées sous forme de trace de pile. Lorsqu'une erreur se produit, la trace de pile remonte aux appels qui ont conduit à l'erreur.

Par exemple, le message d'erreur suivant indique qu'Apple n'est pas un nombre. Combiné avec la pile d'appels, il est possible de réduire les données dans un système complexe où l'erreur s'est produite. Le message seul est généralement insuffisant, car l'algorithme NumberUtil peut être utilisé dans de nombreux emplacements.

Thread.run()
  HttpFramework.service()
    HttpFramework.dispatch()
      ShoppingCart.update()
        ShoppingCart.updateCart()
          ShoppingCart.parseQuantity()
            ShoppingCart.convertParams()
              NumberUtil.convert()  <-- Error: "Apple is not a number"
 

Pour comprendre pourquoi l'erreur s'est produite, utilisez la pile de rappels pour remonter de l'erreur à la méthode métier appropriée, qui est dans ce cas ShoppingCart.parseQuantity().

Les piles d'appels elles-mêmes sont insuffisantes pour la surveillance. Ils ne sont pas faciles à lire et ne fournissent pas d'informations permettant de corréler les performances et la disponibilité d'un système à la santé globale. Pour voir ce qui se passe sur une exécution de code et pour établir une corrélation, prenez en compte des informations telles que l'activité des processus, l'utilisation des ressources, la mise en file d'attente, les modèles d'accès, la charge et le débit, le système et la santé des applications.

Avec l'introduction des architectures orientées service (SOA), la pile d'appels est séparée. Par exemple, la logique ShoppingCart peut désormais résider sur le serveur A, tandis que NumberUtil se trouve sur le serveur B. Une trace d'erreur sur le serveur B contient uniquement la pile d'appels courte de l'erreur d'analyse. Sur le serveur A, une nouvelle erreur est générée indiquant qu'une erreur s'est produite sur le serveur B, mais pas le problème lui-même.

Au lieu d'une seule pile d'appels d'erreur facile à identifier et à résoudre, vous vous retrouvez avec deux piles d'appels avec deux erreurs. De plus, comme aucune connexion n'existe entre les deux, il est impossible d'avoir accès aux deux en même temps.

Serveur A :

Thread.run()
  HttpFramework.service()
    HttpFramework.dispatch()
      ShoppingCart.update()
        ShoppingCart.updateCart()
          ShoppingCart.parseQuantity()
            ShoppingCart.convertParams()
              RestClient.invokeConversion() <-- Error: Unkown
 

Serveur B :

Thread.run()
  HttpFramework.service()
    HttpFramework.dispatch()
      NumberUtil.convert()  <-- Error: "Apple is not a number"
 

L'idée derrière le traçage distribué est de résoudre ce problème en connectant les deux piles d'appels d'erreur l'une à l'autre. La plupart des implémentations utilisent un mécanisme simple pour le faire ; lorsque le serveur A appelle le serveur B, l'outil de surveillance des performances de l'application (APM) ajoute un identificateur à l'appel qui sert de point de référence commun entre les piles d'appels du système APM. Ce mécanisme est appelé corrélation ; pour générer une erreur, il joint les deux piles d'appels.

Thread.run()
  HttpFramework.service()
    HttpFramework.dispatch()
      ShoppingCart.update()
        ShoppingCart.updateCart()
          ShoppingCart.parseQuantity()
            ShoppingCart.convertParams()
              RestClient.invokeConversion()
                Thread.run()
                  HttpFramework.service()
                    HttpFramework.dispatch()
                      NumberUtil.convert()  <-- Error: "Apple is not a number"
 

En comprenant où l'appel distant a lieu et sur quelles parties serveur de la pile d'appels ont été exécutées, vous pouvez découvrir que le ShoppingCart était le contexte de l'erreur et que NumberUtil a provoqué l'échec de l'activité du panier.

Toutefois, les exemples précédents illustrent que les outils APM tracent les erreurs en utilisant le même mécanisme que celui utilisé pour la prise et la présentation des mesures de performances. La trace est annotée avec des numéros de performance comme suit:

413 Thread.run()
413   HttpFramework.service()
413     HttpFramework.dispatch()
412       ShoppingCart.update()
411         ShoppingCart.updateCart()
211           ShoppingCart.parseQuantity()
210             ShoppingCart.convertParams()
200               RestClient.invokeConversion()
 10                 Thread.run()
 10                   HttpFramework.service()
 10                     HttpFramework.dispatch()
  5                       NumberUtil.convert()
 

Le temps total nécessaire à la mise à jour du panier s'élève à environ 413 ms. La conversion numérique (NumberUtil.convert()) a pris 5 ms. Le temps écoulé entre ces deux opérations est réparti entre de nombreux appels; vous recherchez donc des pics significatifs. Dans l'exemple, la mise à jour du panier (ShoppingCart.updateCart()) a pris un total de 411 ms, tandis que l'analyse syntaxique (ShoppingCart.parseQuantity()) n'a nécessité que 211 ms, ce qui a nécessité la majeure partie du temps nécessaire à l'exécution de l'appel distant.

La continuité du traçage signifie que les appels déclenchés par une demande externe sont collectés dans une seule trace. Instana utilise des méthodes spécifiques à chaque protocole pour ajouter des métadonnées, telles que les en-têtes HTTP, les métadonnées gRPC, les en-têtes de message Kafka, les en-têtes AMQP, les en-têtes JMS, etc. L'ajout de métadonnées garantit la continuité de trace dans tous les protocoles et services.

Les protocoles de communication sans prise en charge des métadonnées ne prennent pas en charge la continuité de trace, ce qui signifie que lorsque vous appelez un autre service via un tel protocole, l'appel sortant est une feuille dans l'arborescence de trace. Le travail qui se produit dans le récepteur de l'appel ne fait pas partie de cette trace. A la place, la réception de l'appel démarre une nouvelle trace et tous les appels ultérieurs qui sont déclenchés dans le destinataire appartiennent à cette nouvelle trace.

La continuité du traçage n'est pas prise en charge dans les cas suivants :

• Kafka jusqu'à la version 0.10 (en-têtes introduits parKafka dans la version 0.11)
• L'envoi ou la réception de messages Kafka avec le package Node.js kafka-node (c'est-à-dire que le package ne prend pas en charge les en-têtes. Lorsque vous utilisez la fonction ` Kafka ` dans ` Node.js `, utilisez le package ` kafkajsnpm ` à la place de `trace kafka-node ` car kafkajs il prend en charge la continuité des traces. Pour plus d'informations, consultez les remarques supplémentaires concernant la poursuite du suivi des messages entrants)
• Messagerie en continu NATS et NATS
• Microsoft Message Queue

Les traceurs d' Instana s suivants prennent en charge la spécification de contexte de trace W3C pour les communications via HTTP ou HTTPS, en plus des en-têtes propriétaires tels que X-INSTANA-T ou X-INSTANA-S:

• .NET Core
• .NET
• HTTPd
• Clojure
• Go
• Haskell
• Java
• Kotlin
• Node.js
• Python
• Ruby
• Scala

Les traceurs d' Instana s suivants ne prennent actuellement pas en charge la spécification de contexte de trace W3C. Seuls les en-têtes propriétaires tels que X-INSTANA-T ou X-INSTANA-S sont pris en charge:

• Envoy
• NGINX
• PHP

Afin d'assurer la continuité des traces entre les différents services, les traceurs d' Instana utilisent différents en-têtes ou propriétés de métadonnées, en fonction du protocole.