Rastreamento distribuído é um tópico divisivo. Uma vez que o , esperava-se que a tecnologia revolucionasse a observabilidade. decano de cada KubeCon Avanço rápido de 5 anos, o hype diminuiu um pouco, há 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 depois do Kubernetes. Então, qual é o negócio com Rastreamento Distribuído? Deve-se implementá-lo imediatamente ou esperar e observar? muito mais conversas sobre a dor segundo maior projeto CNCF Neste artigo, vamos explorar o rastreamento distribuído em profundidade O que há de especial no Rastreamento Distribuído e por que precisamos dele? Quais são os problemas com rastreamento distribuído hoje? 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 como a unidade de observabilidade. Em uma plataforma de monitoramento/métrica, um (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? solicitação componente Com logs, a unidade fundamental a ser observada é um - 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. evento 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 . E, como resultado, também é o mais intuitivo de como gostaríamos de examinar e solucionar problemas de arquiteturas distribuídas. mais próxima da final experiência do usuário 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 , 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." sistemas de solicitação-resposta - 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 em 2019. O OpenTelemetry é amplamente popular e tem milhares de colaboradores em todo o mundo o OpenTelemetry 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. para resolver problemas de produção. 73% das empresas relatam que hoje leva mais de uma hora 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 - precisa ser instrumentado para obter um rastreamento distribuído ou o rastreamento é interrompido. cada serviço ou componente 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 para gerar rastreamentos utilizáveis. conjunto coletivo de serviços 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 . 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. cada solicitação Embora o log também faça a mesma coisa (e emita por solicitação, que são gerenciados por ferramentas massivas de agregação de log), a diferença é que a maioria das empresas hoje 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. mais dados já possui Para lidar com esse problema de custo, todos os sistemas de rastreamento distribuído hoje usam 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. amostragem 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 existe. Gerei o erro, mas não consigo encontrar o rastreamento correspondente". que sei 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 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. o que aconteceu no serviço 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: O rastreamento distribuído é difícil de implementar O Rastreamento Distribuído precisa de ampla amostragem para controlar os custos Mas a amostragem reduz consideravelmente o valor 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. do OpenTelemetry já permitem isso para algumas linguagens de programação (no entanto, ficam aquém em linguagens compiladas como Go). Paralelamente, estão evoluindo para . Entre os dois, podemos esperar com segurança que o problema de instrumentação seja resolvido em alguns anos. As bibliotecas de auto-instrumentação tecnologias como eBPF permitir a instrumentação de todo o sistema sem alteração de código 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 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. amostragem baseada em cauda 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 , no entanto, ainda não está maduro e possui vários (devido ao problema mencionado acima). Enquanto isso, várias empresas, incluindo , estão trabalhando no uso da IA para tornar a detecção de anomalias eficiente e escalável. coletor de amostragem baseado em cauda desafios de escalabilidade a ZeroK.ai 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, . É assim que o estado final do rastreamento distribuído pode parecer - embora ainda não esteja aqui, é visível de onde estamos hoje. substituindo o registro 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.
