Usar o rastreamento distribuído para observar a latência do microsserviço

Last reviewed 2023-08-11 UTC

Quando um aplicativo é reescrito para usar microsserviços, o número de componentes e endpoints envolvidos em uma única transação de usuário aumenta. Portanto, a observabilidade é essencial para operar serviços do usuário de maneira confiável. Esta arquitetura de referência mostra como capturar informações de trace em aplicativos de microsserviço usando o OpenTelemetry e o Cloud Trace.

Este documento é destinado a desenvolvedores, SREs e engenheiros de DevOps que querem entender os fundamentos do rastreamento distribuído e que querem aplicar esses princípios aos serviços para melhorar a observabilidade do serviço.

.

Arquitetura

O diagrama a seguir mostra a arquitetura de um aplicativo que implementa essa arquitetura.

Arquitetura de uma implantação de amostra com dois clusters do GKE.

Conforme ilustrado no diagrama anterior, essa arquitetura inclui dois clusters do GKE. Você implanta um aplicativo em cada um dos clusters. O tráfego do usuário é enviado para o aplicativo de front-end no cluster de front-end. O pod de front-end no cluster de front-end se comunica com o pod de back-end no cluster de back-end. O pod de back-end chama um endpoint de API externo.

Os dados de observação são exportados para o Cloud Trace, que rastreia como as solicitações se propagam pelos aplicativos.

Considerações sobre o design

Para serviços executados no Kubernetes, é possível usar uma malha de serviço como o Istio para ativar o rastreamento distribuído de serviços para tráfego de serviço sem a necessidade de instrumentação dedicada. No entanto, você pode ter qualquer um dos seguintes requisitos:

  • Você quer ter mais controle sobre os traces do que o Istio oferece.
  • Talvez seja necessário capturar os dados internos do aplicativo nas informações de rastreamento.
  • Talvez seja necessário rastrear o código que não está em execução no Kubernetes.

Para esses casos de uso, você pode usarOpenTelemetry , que é uma biblioteca de código aberto que pode adicionar instrumentação a aplicativos de microsserviço distribuídos para coletar traces, métricas e registros em uma ampla variedade de linguagens, plataformas e ambientes.

Noções básicas sobre traces, períodos e contexto

O conceito de rastreamento distribuído é descrito no documento de pesquisa do Dapper (em inglês) publicado pelo Google. Conforme descrito no documento, o diagrama a seguir mostra cinco períodos em um trace.

Rastreamento distribuído com cinco períodos em um trace.

Um trace é o total de informações que descrevem como um sistema distribuído responde a uma solicitação do usuário. Os traces são compostos por períodos, em que cada período representa uma solicitação e um par de resposta específicos envolvidos na disponibilização da solicitação do usuário. O período pai descreve a latência conforme observado pelo usuário final. Cada um dos períodos filhos descreve como um determinado serviço no sistema distribuído foi chamado e respondido, com informações de latência capturadas para cada um deles.

O diagrama mostra uma única solicitação de front-end que faz duas solicitações de back-end. A segunda chamada de back-end requer que duas chamadas auxiliares sejam concluídas. Cada chamada é identificada com o código do período e o código do período pai.

Um desafio com o rastreamento em sistemas distribuídos é que as informações sobre a solicitação de front-end original não são transportadas de forma automática ou herdada quando solicitações subsequentes são feitas para vários serviços de back-end.

Com algumas ferramentas (por exemplo, na linguagem Go), é possível fazer solicitações com contexto (o endereço IP e as credenciais do cluster). O OpenTelemetry estende o conceito de contexto para incluir contexto de período, o que significa que informações adicionais são carregadas no cabeçalho HTTP. As informações sobre o período pai podem ser incluídas em cada solicitação subsequente. Em seguida, é possível anexar períodos filhos para compor o rastreamento geral. Assim, é possível ver como a solicitação do usuário passou pelo sistema e, por fim, foi atendida novamente.

Implantação

Para implantar essa arquitetura, consulte Implantar o rastreamento distribuído para observar a latência do microsserviço.

A seguir