Conceitos de rastreio

Uma pilha de chamada é uma lista ordenada de execuções de código. Sempre que o código chama outro código, o novo código é colocado na parte superior da pilha. As pilhas de chamada são usadas por tempos de execução de todas as linguagens de programação e são geralmente impressas como um rastreio de pilha Quando ocorre um erro, o rastreio de pilha rastreia de volta às chamadas que levaram ao erro.

Por exemplo, a mensagem de erro a seguir afirma que Maçã não é um número. Combinado com a pilha de chamada, é possível reduzir em um sistema complexo onde o erro ocorreu. A mensagem por si só é geralmente insuficiente, uma vez que o algoritmo NumberUtil pode ser usado em muitos lugares.

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

Para entender o motivo do erro, use a pilha de chamada para rastrear o erro de volta para o método de negócios relevante, que neste caso, é ShoppingCart.parseQuantity().

As próprias pilhas de chamada são insuficientes para o monitoramento. Eles não são fáceis de ler e não fornecem informações para correlacionar o desempenho e a disponibilidade de um sistema com o funcionamento geral. Para ver o que acontece em uma execução de código e correlacionar, considere informações como atividade de processo, uso de recursos, enfileiramento, padrões de acesso, carregamento e rendimento, funcionamento do sistema e do aplicativo

Com a introdução de arquiteturas orientadas a serviços (SOA), a pilha de chamada é dividida.. Por exemplo, a lógica ShoppingCart agora pode residir no servidor A, enquanto NumberUtil reside no servidor B. Um rastreio de erro no servidor B contém apenas a pilha de chamada curta do erro de análise.. Enquanto no servidor A, um novo erro é produzido indicando que algo deu errado no servidor B, mas não indicando o problema em si.

Em vez de uma única pilha de chamada de erro que é fácil de resolver, você termina com duas pilhas de chamada com dois erros. Além disso, como não existe conexão entre os dois, torna impossível ter acesso a ambos ao mesmo tempo.

Servidor A:

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

Servidor B:

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

A ideia por trás do rastreio distribuído é corrigir esse problema conectando as duas pilhas de chamadas de erro entre si. A maioria das implementações usa um mecanismo simples para fazer isso; quando o servidor A chama o servidor B, a ferramenta de monitoramento de desempenho do aplicativo (APM) inclui um identificador na chamada que serve como um ponto de referência comum entre as pilhas de chamadas no sistema APM. Esse mecanismo é chamado correlação e para produzir um erro, ele une as duas pilhas de chamada.

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"
 

Ao entender onde a chamada remota ocorre e em quais partes do servidor da pilha de chamada foram executadas, é possível descobrir que o ShoppingCart foi o contexto do erro e o NumberUtil causou a falha da atividade do carrinho de compras.

No entanto, os exemplos anteriores ilustram que as ferramentas APM rastreiam erros usando o mesmo mecanismo usado para obter e apresentar medições de desempenho. O rastreio é anotado com números de desempenho conforme mostrado:

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()
 

O tempo total para executar a atualização do carrinho de compras é de aproximadamente 413 ms. A conversão numérica (NumberUtil.convert()) levou 5 ms. O tempo gasto entre essas duas etapas está distribuído por várias chamadas, portanto, você deve procurar por picos significativos. No exemplo, a atualização do carrinho (ShoppingCart.updateCart()) levou um total de 411 ms, enquanto a análise (ShoppingCart.parseQuantity()) exigiu apenas 211 ms, que por si só gastou a maior parte do tempo fazendo a chamada remota.

A continuidade de rastreio significa que as chamadas acionadas por uma solicitação externa são coletadas em um rastreio. Instana utiliza métodos específicos de protocolo para adicionar metadados, tais como cabeçalhos do HTTP, metadados do gRPC, cabeçalhos de mensagem do Kafka, cabeçalhos AMQP, cabeçalhos JMS e outros. Incluir metadados assegura a continuidade de rastreio em todos os protocolos e serviços.

Protocolos de comunicação sem suporte para quaisquer metadados não suportam continuidade de rastreio, o que significa que quando você chama outro serviço sobre tal protocolo, a chamada de saída é uma folha na árvore de rastreio. O trabalho que acontece no receptor da chamada não faz parte desse rastreio. Em vez disso, o recebimento da chamada inicia um novo rastreio e todas as chamadas subsequentes acionadas no receptor pertencem a esse novo rastreio.

A continuidade de rastreio não é suportada nos casos a seguir:

• Kafka até a versão 0.10 (oKafka introduziu cabeçalhos na versão 0.11)
• Enviar ou receber mensagens do Kafka com o pacote Node.js kafka-node (ou seja, o pacote não suporta cabeçalhos) Ao trabalhar com o ` Kafka ` no ` Node.js `, utilize o pacote ` npmkafkajs ` em vez de `trace` kafka-node , pois kafkajs este suporta a continuidade do rastreamento. Para obter mais informações, consulte as observações adicionais sobre como continuar o rastreamento de mensagens recebidas)
• Mensagens de streaming NATS e NATS
• Microsoft Message Queue

Os seguintes rastreadores do Instana suportam a especificação de contexto de rastreamento W3C para comunicações HTTP ou HTTPS, além de cabeçalhos proprietários como X-INSTANA-T ou X-INSTANA-S:

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

Os seguintes rastreadores do Instana não oferecem suporte, no momento, à especificação de contexto de rastreamento W3C. Apenas os cabeçalhos proprietários como X-INSTANA-T ou X-INSTANA-S são suportados:

• Envoy
• NGINX
• PHP

Para garantir a continuidade do rastreamento entre diferentes serviços, os rastreadores do Instana utilizam diferentes cabeçalhos ou propriedades de metadados, dependendo do protocolo.