Rastreamento distribuído: passado, presente e futuro

Rastreamento distribuído é um tópico divisivo. Uma vez que o decano de cada KubeCon , esperava-se que a tecnologia revolucionasse a observabilidade.

Avanço rápido de 5 anos, o hype diminuiu um pouco, há muito mais conversas sobre a dor e a adoção é moderada. Enquanto isso, continua a haver uma atividade constante em torno da expansão e padronização da tecnologia - a Open Telemetry (baseada no OpenTracing) é o segundo maior projeto CNCF depois do Kubernetes. Então, qual é o negócio com Rastreamento Distribuído? Deve-se implementá-lo imediatamente ou esperar e observar?

Neste artigo, vamos explorar o rastreamento distribuído em profundidade

1. O que há de especial no Rastreamento Distribuído e por que precisamos dele?
2. Quais são os problemas com rastreamento distribuído hoje?
3. Quais são os próximos desenvolvimentos e como eles abordam os desafios existentes?

Introdução - Como funciona o rastreamento distribuído

Para os não iniciados, o Rastreamento Distribuído é uma tecnologia que nos permite rastrear uma única solicitação enquanto ela atravessa vários componentes/microsserviços diferentes de um ambiente distribuído. Cada chamada de rede feita no caminho da solicitação é capturada e representada como um span.

Para permitir isso, as ferramentas de rastreamento distribuído inserem um contexto de rastreamento exclusivo (ID de rastreamento) no cabeçalho de cada solicitação e implementam mecanismos para garantir que o contexto de rastreamento seja propagado por todo o caminho da solicitação.

Como um rastreamento distribuído representa um caminho de solicitação

Por que precisamos do Rastreamento Distribuído em primeiro lugar

O rastreamento distribuído é exclusivo porque se concentra em uma solicitação como a unidade de observabilidade. Em uma plataforma de monitoramento/métrica, um componente (por exemplo, um serviço, host) é a unidade fundamental que está sendo observada. Pode-se fazer perguntas a essas plataformas sobre o comportamento dessa unidade como um todo, ao longo do tempo. Por exemplo, qual é a taxa de integridade/taxa de transferência/erro deste serviço em um período de tempo específico?

Com logs, a unidade fundamental a ser observada é um evento - por exemplo, sempre que um evento ocorrer durante a execução do código, imprima algumas informações. Esses "eventos" são definidos subjetivamente pelos desenvolvedores enquanto escrevem o código. O desafio com os logs é que eles são todos separados, com cada componente imprimindo sua própria forma de mensagens de log isoladamente, sem uma maneira fácil de conectá-los para fazer sentido.

Em contraste, com o rastreamento distribuído, o que está sendo observado é uma única solicitação que percorre vários componentes. Isso nos permite fazer perguntas sobre o sistema distribuído como um todo e entender o que ocorreu em um sistema complexo e interconectado.

O argumento básico para rastreamento distribuído reside no argumento de que essa orientação em torno de solicitações é a mais próxima da experiência do usuário final . E, como resultado, também é o mais intuitivo de como gostaríamos de examinar e solucionar problemas de arquiteturas distribuídas.

A evolução do rastreamento distribuído

O rastreamento distribuído aumentou em importância devido à ampla adoção de arquiteturas de software distribuídas na última década.

A arquitetura moderna baseada em microsserviços é uma evolução da história de crescimento da internet no final dos anos 90, quando se tornou comum o uso de sistemas de solicitação-resposta .

"Com o final dos anos 90 e o crescimento explosivo da internet, veio a enorme proliferação de sistemas de solicitação-resposta , como sites de duas camadas, com um front-end de servidor web e um back-end de banco de dados... Os pedidos eram uma nova dimensão para raciocinar sobre sistemas , ortogonal a qualquer máquina ou processo em conjunto."

- Rastreamento distribuído na prática, O'Reilly Media

Nessas arquiteturas de microsserviços, cada solicitação acaba atingindo muitas (dezenas ou até centenas de microsserviços), fazendo várias chamadas de rede entre elas. Consulte abaixo a arquitetura de microsserviços da Uber, que possui mais de 3.000 serviços.

Arquitetura de microsserviços da Uber de 2018. Fonte: https://www.uber.com/en-IN/blog/microservice-architecture/

Em tais sistemas complexos, o rastreamento distribuído torna-se crítico para qualquer forma de solução de problemas. Como resultado, o Distributed Tracing foi iniciado por grandes empresas que foram as primeiras a adotar ambientes distribuídos grandes e complexos.

• O artigo Dapper do Google lançado em 2010 foi o início do rastreamento distribuído

  
  

• Nos anos seguintes, mais duas empresas abriram seus próprios sistemas de rastreamento distribuído (Zipkin, de código aberto, do Twitter, em 2012, e Jaeger, de código aberto, da Uber, em 2017). Zipkin e Jaeger continuam entre as ferramentas de rastreamento distribuído mais populares até hoje

  
  

• Desde 2016, houve um esforço significativo para padronizar o rastreamento distribuído entre componentes por meio do projeto OpenTracing. O OpenTracing acabou se tornando o OpenTelemetry em 2019. O OpenTelemetry é amplamente popular e tem milhares de colaboradores em todo o mundo

  
  

• Agora o Rastreamento Distribuído é amplamente considerado como o terceiro "pilar" de observabilidade junto com métricas e logs. A maioria dos principais players de monitoramento e observabilidade fornece ferramentas de rastreamento distribuídas como parte de seus produtos.

Estado do Rastreamento Distribuído: Teoria vs Realidade

No entanto, apesar da promessa, empolgação e esforço da comunidade, a adoção do rastreamento distribuído hoje é de cerca de 25%. Não é incomum encontrar empresas com arquiteturas de microsserviços que se contentam com logs e métricas, embora claramente precisem de rastreamento distribuído.

Ao mesmo tempo, os erros de produção de tempo médio para resolver estão aumentando no mundo de hoje. 73% das empresas relatam que hoje leva mais de uma hora para resolver problemas de produção.

Pergunte a qualquer desenvolvedor quais são os momentos mais dolorosos de sua vida e eles falarão sobre o tempo gasto depurando um erro Sev-1 na produção com o que parecia ser algumas centenas de pessoas respirando fundo.

Parece então que qualquer empresa que se preocupa com seu MTTR (que é quase toda empresa) deveria estar usando rastreamento distribuído, e a adoção deveria ter disparado neste ambiente. Mas os números reais não suportam isso - então o que dá?

Desafios com Rastreamento Distribuído hoje

Existem vários problemas com rastreamento distribuído hoje que as empresas precisam superar para obter valor - todos os quais não são discutidos tão amplamente na narrativa convencional.

1. A implementação é difícil!

Para implementar o rastreamento distribuído em um serviço hoje, precisamos fazer uma alteração de código e um lançamento. Embora fazer alterações no código seja uma solicitação bastante comum de observabilidade, o desafio especificamente com o rastreamento distribuído é este - cada serviço ou componente precisa ser instrumentado para obter um rastreamento distribuído ou o rastreamento é interrompido.

Não se pode simplesmente começar com um único serviço - como é possível com monitoramento ou registro - e obter valor. O rastreamento distribuído requer instrumentação em um conjunto coletivo de serviços para gerar rastreamentos utilizáveis.

Isso requer coordenação entre várias equipes e proprietários de serviços para fazer alterações em seus serviços. Portanto, torna-se um problema organizacional - imagine obter 100 equipes para instrumentar seus serviços ao longo de vários meses antes que você possa perceber o valor.

Esse é o maior desafio do rastreamento distribuído atualmente.

2. Necessidade de decisões de amostragem complexas

Em seguida, o volume de dados de rastreamento gerados pelo Rastreamento Distribuído pode ser esmagador. Imagine centenas de serviços, cada um emitindo uma pequena quantidade de dados de rastreamento para cada solicitação . Isso representará milhões de solicitações por segundo e torna o rastreamento distribuído caro em termos de armazenamento e largura de banda da rede.

Embora o log também faça a mesma coisa (e emita mais dados por solicitação, que são gerenciados por ferramentas massivas de agregação de log), a diferença é que a maioria das empresas hoje já possui log. A introdução de mais um tipo de dados que será quase tão volumoso quanto o registro é uma tarefa assustadora e provavelmente dobrará o gasto.

Para lidar com esse problema de custo, todos os sistemas de rastreamento distribuído hoje usam amostragem e registram apenas um subconjunto de rastreamentos. As taxas de amostragem comuns na prática hoje estão entre 0,1% e 2%. A justificativa é que mesmo 1% das amostras são suficientes para fornecer uma imagem agregada decente de onde estão os gargalos de desempenho.

A maioria das plataformas hoje permite que os clientes escolham sua estratégia de amostragem e façam suas próprias compensações de visibilidade de custo. No entanto, esse processo de decisão aumenta a já complexa sobrecarga de instrumentação e gerenciamento de um sistema de rastreamento distribuído.

3. Mas a amostragem diminui significativamente o valor

Vamos supor que uma empresa se esforce para instrumentar todos os serviços/componentes e, em seguida, decidir a estratégia de amostragem para garantir que eles não quebrem o banco.

E agora - devemos esperar que o MTTR caia drasticamente? Não, porque os desenvolvedores não podem usar rastreamento distribuído para realmente solucionar problemas, devido à amostragem.

Imagine a experiência de um desenvolvedor - "Não consigo encontrar o problema que sei que existe. Gerei o erro, mas não consigo encontrar o rastreamento correspondente".

Então o que acontece? Os desenvolvedores param de confiar na qualidade dos dados de rastreamento distribuído e revertem para seus métodos regulares de depuração/solução de problemas (ou seja, usando logs)

4. O uso do desenvolvedor é de baixa frequência

Dadas essas restrições, hoje o Distributed Tracing é vendido principalmente como uma forma de solucionar problemas de desempenho .

Lembre-se de que um rastreamento distribuído básico realmente nos diz quem ligou para quem e quanto tempo durou cada span. Os traces distribuídos não nos informam o que aconteceu no serviço que causou o erro/alta latência. Para isso, os desenvolvedores ainda precisam examinar a mensagem de log e/ou reproduzir o problema localmente para depurar.

Em uma empresa típica, os problemas de desempenho provavelmente são <10% do total. Portanto, na realidade, o rastreamento distribuído é útil apenas para esse pequeno segmento de problemas.

O desenvolvedor médio que envia e possui um serviço está usando uma ferramenta de rastreamento distribuído talvez 2 a 3 vezes por ano.

Impacto de todos esses desafios

Resumindo:

1. O rastreamento distribuído é difícil de implementar
2. O Rastreamento Distribuído precisa de ampla amostragem para controlar os custos
3. Mas a amostragem reduz consideravelmente o valor
4. Como resultado, os desenvolvedores usam o rastreamento apenas para o caso de uso de desempenho único e ímpar

Tudo isso torna o caso RoI para rastreamento distribuído bastante vago.

Em um ciclo típico de hype, o que podemos dizer é que já passamos do estágio de expectativas infladas e a desilusão está começando a se instalar.

Se pensarmos em termos de estado final, porém, se o futuro dos sistemas de computação for distribuído, então o rastreamento distribuído é naturalmente o vetor mais fundamental para a observabilidade. Nesse mundo, qualquer empresa com uma arquitetura distribuída usa o rastreamento como o principal mecanismo para solucionar qualquer problema que ocorra na produção - verdadeira "observabilidade" - versus o monitoramento passivo de sistemas que temos hoje.

Antes de chegarmos a esse estado final, porém, precisaremos de várias melhorias em relação ao status quo. A boa notícia é que muito disso já está em andamento. Vejamos cada um deles. Então, o que podemos esperar ver no futuro?

Futuro do rastreamento distribuído

Instrumentação instantânea sem alterações de código

Imagine entrar em um agente e ser capaz de cobrir todo um sistema distribuído (todos os serviços, componentes) de uma só vez, sem alterações de código.

Isso parece realisticamente possível nos próximos 2-3 anos.

As bibliotecas de auto-instrumentação do OpenTelemetry já permitem isso para algumas linguagens de programação (no entanto, ficam aquém em linguagens compiladas como Go). Paralelamente, tecnologias como eBPF estão evoluindo para permitir a instrumentação de todo o sistema sem alteração de código . Entre os dois, podemos esperar com segurança que o problema de instrumentação seja resolvido em alguns anos.

A amostragem dá lugar à seleção baseada em IA de solicitações de interesse

Em um mundo LLM, a amostragem aleatória começa a parecer uma relíquia da idade das trevas. Idealmente, devemos ser capazes de examinar 100% dos traços, identificar qualquer coisa que pareça anômala e armazená-la para exame futuro. Não há mais amostragem aleatória.

Se pensarmos bem, realmente não nos importamos com os ~95% de "pedidos felizes". Nós nos preocupamos apenas com aproximadamente 5% dos rastreamentos anômalos - erros, exceções, alta latência ou alguma forma de erros de software. Então, só precisamos de uma maneira de olhar para 100% e escolher os 5% interessantes.

Existem mecanismos como amostragem baseada em cauda que visam fazer isso hoje. Na amostragem baseada na cauda, o sistema espera até que todos os spans em uma solicitação sejam concluídos e, com base no rastreamento completo, decide se ele deve ser retido.

O principal desafio da amostragem baseada na cauda é que você precisa armazenar todos os intervalos de um rastreamento até que toda a solicitação seja concluída e, então, decidir se deseja manter/descartar o rastreamento. Isso significa que armazenamos cada solicitação, com todos os períodos, por um determinado período (até que a solicitação seja concluída) - isso requer uma arquitetura de dados separada com componentes para balanceamento de carga, armazenamento e processamento altamente complexos e caros.

O OpenTelemetry possui um coletor de amostragem baseado em cauda , no entanto, ainda não está maduro e possui vários desafios de escalabilidade (devido ao problema mencionado acima). Enquanto isso, várias empresas, incluindo a ZeroK.ai , estão trabalhando no uso da IA para tornar a detecção de anomalias eficiente e escalável.

Com o ritmo acelerado de desenvolvimento neste espaço, podemos razoavelmente esperar que este problema também seja resolvido nos próximos 3-5 anos.

O surgimento de traços distribuídos "ricos" que permitem toda a depuração

Um verdadeiro salto para a próxima geração de rastreamento será quando o rastreamento evoluir do domínio de "somente problemas de desempenho" para "todos os problemas". É aí que o verdadeiro poder do rastreamento distribuído é liberado.

Para que isso seja possível, cada traço precisa ter um contexto rico.

Imagine um cenário onde cada extensão em cada traço tem:

• Payloads de solicitação e resposta (com mascaramento de PII)

• Rastreamentos de pilha para quaisquer exceções

• Histórico

• Eventos do Kubernetes

• Estados do pod

• E qualquer outra coisa que ocorreu ao longo desse período

  
  

Tudo em um fluxo integrado e contínuo.

E imagine se o rastreamento que você está procurando for superfácil de encontrar - não há lacunas de dados relacionadas à amostragem, os problemas são desduplicados e agrupados e podem ser filtrados em várias dimensões.

Isso é tudo que um desenvolvedor precisa para depurar qualquer problema de software. E, potencialmente, tudo o que um modelo de IA precisa para diagnosticar e apontar ao desenvolvedor o que está errado.

Neste mundo, o traço torna-se o eixo principal da observabilidade, substituindo o registro . É assim que o estado final do rastreamento distribuído pode parecer - embora ainda não esteja aqui, é visível de onde estamos hoje.

A principal barreira para tornar isso possível é a explosão no volume de dados que o armazenamento de todos esses dados de contexto causará. Exigiremos profunda inovação em processamento de dados e arquiteturas de armazenamento para tornar isso possível. Ainda é cedo e temos que esperar para ver o que acontece aqui.

Resumo

Em resumo, o Rastreamento Distribuído é uma visão necessária e intuitiva necessária para poder observar arquiteturas de aplicativos distribuídos em produção.

A primeira geração de rastreamento distribuído, embora promissora, foi cercada por vários desafios que tornaram difícil para as empresas obter valor do rastreamento, o que impediu um pouco a adoção.

No entanto, vários desenvolvimentos empolgantes estão ocorrendo no espaço, que devem tornar o rastreamento mais fácil, simples e poderoso do que o que temos hoje, tornando a observabilidade mais perfeita no futuro.