O que é rastreamento distribuído (conhecido como Tracing), e quais são seus principais componentes? E mais importante ainda: por que você deve investir tempo na integração do rastreamento distribuído em sua pilha de tecnologia? Embora haja muitos motivos, vamos tratar neste post dos mais significativos.
Revela dependências de serviço
A decisão estratégica foi tomada: sua empresa começou a migrar para uma arquitetura distribuída, o número de componentes começou a aumentar e a capacidade de entender a arquitetura da organização diminuiu; aplicando o rastreamento distribuído, você pode rastrear o caminho de uma requisição à medida que ela passa por um sistema complexo. Algumas ferramentas até calculam e desenham um grafo de dependência completo. Pode ser útil ter uma visão geral de sua arquitetura e mergulhar profundamente para entender melhor as dependências.
Descubra a latência dos componentes ao longo do caminho
Você pode descobrir a latência monitorando requisições de serviços de borda (edge services) usando sistemas de monitoramento. OK, você recebeu o alerta, mas agora precisa descobrir qual componente faz com que a solicitação específica exceda o Service Level Objective (SLO). É exatamente por isso que o rastreamento distribuído existe: para localizar componentes no caminho que são gargalos ou passíveis de causar falhas.
Análise de causa raiz
Imagine o seguinte cenário – você acorda com um alerta, são 2h da manhã e uma requisição envolvendo 5 microsserviços diferentes está falhando repetidamente. Você procura desesperadamente nos logs, ainda tentando abrir os olhos contra a tela ultra iluminada, em busca de erros na hora do alerta, mas o fluxo de dados é gigantesco demais para descobrir com precisão e rapidez o que aconteceu. Está demorando demais. Pois bem: usando o rastreio distribuído, é possível encontrar o primeiro serviço que falhou, obter os logs dessa falha e algumas outras coisas mais (a depender da implementação de rastreio feita no sistema).
Colete eventos durante a requisição
Para ajudar no processo de debug, é possível adicionar elementos ao rastreamento. Por exemplo, você pode adicionar todas as feature flags avaliadas ao rastreamento para que, em caso de falha, possa saber exatamente quais flags foram avaliadas em cada um dos serviços no caminho da requisição.
Mas, o que é uma ferramenta de rastreamento mesmo?
Vamos começar com o básico, de onde todas as soluções de rastreamento distribuídas se originaram. Embora antes houvesse algumas soluções de rastreamento distribuído, o artigo entitulado Google Dapper (2010), de 14 páginas, é a pedra angular do rastreamento distribuído, por assim dizer. O documento trata de explicar como o Google desenvolveu uma ferramenta de rastreamento em nível de produção, tendo em vista 3 objetivos principais:
1) Baixa sobrecarga – O sistema de rastreamento deve ter um impacto insignificante no desempenho dos serviços em execução. Em alguns serviços altamente otimizados, mesmo pequenas sobrecargas de monitoramento são facilmente perceptíveis. Por exemplo, uma única query de pesquisa do Google percorre milhares de máquinas e serviços; logo, o Google não pode permitir um incremento que não seja desprezível em termos de impacto de desempenho para cada uma dessas requisições.
2) Transparência em nível de aplicativo – O rastreamento não deve exigir colaboração ativa dos programadores, pois pode ser frágil e consumir o precioso (e custoso) tempo dos programadores para aprendê-lo.
3) Escalabilidade – Precisa lidar com a escala do Google por pelo menos alguns anos.
Também há um requisito informando que os dados de rastreamento estarão disponíveis minutos após a solicitação.
Instrumentação de serviço e terminologia
Dapper introduziu também uma terminologia. Pode ser diferente entre as soluções disponíveis no mercado atualmente, mas essas são as ideias fundamentais na maioria das soluções sucessoras ao Dapper:
Rastreamento (Trace): A descrição de uma transação conforme ela se move por um sistema distribuído.
Span: Uma operação nomeada e cronometrada que representa uma parte do fluxo de trabalho. Os spans aceitam tags de chave-valor, bem como logs estruturados, com carimbo de data/hora e granulados, anexados à instância específica do span.
(Span) Context: Rastreia a informação de identificação que acompanha a transação distribuída, incluindo quando ela passa de serviço para serviço pela rede ou por meio de um barramento de mensagem. O span context contém o identificador de rastreamento, o span identifier e quaisquer outros dados que o sistema de rastreamento precisa para propagar para o serviço de downstream.
Instrumentação (Instrumentation): Instrumentação é o processo por meio do qual o código do aplicativo é estendido para capturar e reportar spans de rastreamento para as operações de interesse.
Anotações (annotations, às vezes chamado de baggage): Permite ao desenvolvedor enriquecer o rastreamento com dados definidos pelo usuário, pode ser usado para salvar contadores, logs relevantes e quaisquer dados que possam ajudar a investigar um incidente.
O contexto de rastreamento é serializado e passado durante a chamada entre os serviços instrumentados, determinando se será um RPC, mensagem de evento, SMTP ou qualquer outro canal de comunicação que o desenvolvedor tenha em mente após o cliente enviar os dados de rastreamento para o servidor (por exemplo, por cabeçalho HTTP em chamadas REST). O servidor desserializará o span e iniciará um novo que está apontando para seu span pai, o span foi recebido pelo cliente.
A evolução do Dapper
Agora que contextualizamos o histórico da ferramenta de rastreamento distribuído, vamos aos descendentes disponíveis atualmente no mercado – muitos deles compartilham o mesmo conceito ou a mesma solução que o Dapper.
As soluções atuais podem ser divididas em 2 grupos:
Soluções opensource:
Soluções empresariais:
Quer saber como começar de forma simples com Tracing? Através dos nossos serviços profissionais, podemos te ajudar a escolher a melhor alternativa para o seu cenário e apoiar em toda a configuração e acompanhamento.
