O que Aprendi sobre Observabilidade no Mundo Real
08/03/2026
Trabalhar com software em cenários "normais" não te prepara para o que vi hoje. Quando você ouve números como 15 bilhões de requests por segundo e 35 mil microsserviços, a primeira coisa que você entende é que a observabilidade não é um "extra" — é o que mantém o sistema vivo.
Abaixo, detalho os pilares técnicos e as verdades incômodas dessa jornada.
1. O Fim da Ilusão dos "Vendores"
A primeira grande lição é o abandono do vendor lock-in. No passado, a dependência de ferramentas de terceiros criava gargalos absurdos. Você precisava que o fornecedor atualizasse um agente para você poder fazer um deploy? Isso é inaceitável quando você faz 136 mil deploys por dia.
A decisão de adotar o OpenTelemetry (OTel) foi estratégica:
Agnosticismo: Os dados pertencem à empresa, não ao fornecedor (Datadog, New Relic, etc.).
Governança: Eles criaram seus próprios SDKs e "toolkits" internos. O desenvolvedor não perde tempo configurando dependência de banco de dados; ele usa o que já está catalogado e a instrumentação vem "de brinde".
2. A Matemática do Sampling (Amostragem)
Aqui não há eufemismos: processar 100% de tudo o que acontece em 15 bilhões de requests é impossível ou financeiramente estúpido.
1% de Sampling: No ecossistema geral, apenas 1% dos traces são capturados. Sabe quanto isso gera? 500 milhões de spans por minuto.
O Problema do Agulha no Palheiro: O problema de usar apenas 1% é que, quando um pagamento de um cliente específico falha, a chance de você ter o trace desse erro é mínima.
Para resolver isso, eles criaram a plataforma Olievents. Ela permite 100% de sampling em fluxos críticos (Pix, checkout). Se o negócio é sensível, eles rastreiam cada microssegundo, custe o que custar em processamento.
3. O "Pulo do Gato" nas Métricas
Algo que me chamou a atenção foi a geração de métricas a partir de spans de tracing. Em vez de criar métricas isoladas, eles extraem inteligência dos rastros.
Resultado real: Um time conseguiu reduzir em 25% a ineficiência de um processo apenas analisando a distribuição desses dados.
Não é apenas saber "se caiu", é entender onde o dinheiro está sendo jogado fora por latência desnecessária.
4. Desafios de Engenharia: Além do Backend
A observabilidade está descendo para o Mobile e Browser. Isso é um campo minado. Diferente do backend, onde você controla a rede, no mobile você lida com latência instável, segurança pública (necessidade de proxies e WAF) e impacto na bateria do usuário.
Eles já estão implementando OTel para capturar logs e métricas diretamente do front-end, garantindo que o erro que o usuário vê no celular seja correlacionado com o erro no banco de dados em milissegundos.
5. A Realidade Nua e Crua da Cultura
A tecnologia é a parte fácil. A parte difícil é convencer milhares de desenvolvedores a pararem de olhar apenas para logs e passarem a usar Distributed Tracing.
O log é como olhar pelo retrovisor após a batida. O tracing é o mapa completo do acidente em tempo real. A estratégia deles não foi apenas impor a ferramenta, mas criar uma cultura de "evangelização", workshops e suporte direto. Se o dev tem um problema no coletor, ele fala com um par interno que contribui para o código-fonte do OpenTelemetry, não com um suporte de chatbot de um fornecedor internacional.
Conclusão Técnica
Se a sua empresa está crescendo, o modelo de "instalar um agente e esquecer" vai falhar. A observabilidade moderna exige que você seja o dono dos seus dados. O case apresentado mostra que a eficiência operacional (reduzir custos e tempo de troubleshooting) é o único caminho para sustentar uma arquitetura de milhares de microsserviços.
