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.

Por que precisamos de rastreamento distribuído

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

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.

Visualize métricas, logs e rastreamento distribuído

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.

Imagem da arquitetura de microsserviços da Uber de Jaeger

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.

Adoção 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.

Aumentar MTTRs 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.

Instrumentação de Rastreamento Distribuído

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.

Ciclo de hype - rastreamento distribuído

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.

Traços com os quais nos preocupamos

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.