OpenTelemetry Venceu as Guerras de Observabilidade. Agora Vem a Parte Difícil.

O Problema Que Ninguém Discute o Suficiente

Você está executando um sistema distribuído em produção. Algo está errado — a latência disparou, as taxas de erro subiram, um usuário está abrindo um ticket de suporte. Seu primeiro instinto é olhar os logs. Mas qual serviço? Você tem doze deles. Os logs estão lá, em algum lugar, espalhados por três pilhas de ferramentas diferentes deixadas por engenheiros que já seguiram em frente. Você faz grep. Você pivota. Vinte minutos depois você encontra a causa raiz: uma consulta ao banco de dados que começou a expirar porque uma migração de esquema foi executada no host errado.

Este é o problema de observabilidade. Não a alerta. Não os painéis. O problema fundamental: entender o que realmente está acontecendo dentro dos seus sistemas quando as coisas dão errado — e cada vez mais, antes que elas deem errado. Os três sinais canônicos são logs (eventos discretos), métricas (medições numéricas ao longo do tempo) e rastreamentos (a jornada de uma requisição através de um sistema distribuído). Antes do OpenTelemetry, coletar todos os três de forma coerente e portátil era genuinamente doloroso.

A Era do Lock-In

Cada fornecedor de observabilidade — Datadog, New Relic, Dynatrace, Honeycomb, Jaeger — enviava seu próprio SDK. Seu próprio agente. Seu próprio protocolo de rede. Se você instrumentou seu serviço Python com o tracer do Datadog e depois decidiu avaliar o Honeycomb, você teria que reescrever sua camada de instrumentação. Não porque os fornecedores estavam sendo maliciosos, mas porque não havia um padrão. A camada de coleta de telemetria era o fosso.

Isso não era um pequeno incômodo. Significava que as equipes estavam tomando decisões sobre fornecedores cedo, antes de terem dados de produção suficientes para saber o que realmente precisavam. Significava que as equipes de plataforma gastavam ciclos de engenharia mantendo múltiplos pipelines de telemetria. Significava que os custos de troca eram altos o suficiente para que a maioria das equipes simplesmente não trocasse — mesmo quando uma ferramenta melhor surgia.

De Onde Veio o OpenTelemetry

Em 2019, dois projetos concorrentes de observabilidade de código aberto — OpenCensus (apoiado pelo Google) e OpenTracing (um projeto da CNCF) — se fundiram no OpenTelemetry. A fusão evitou o que teria sido uma fragmentação prejudicial do ecossistema. O OpenTelemetry se tornou um projeto da CNCF e cresceu rápido. Por número de contribuidores, é agora o segundo projeto mais ativo da CNCF depois do Kubernetes.

A proposta de valor era simples: instrumente uma vez, exporte para qualquer lugar. Um SDK por linguagem. Um protocolo de rede — OTLP (OpenTelemetry Protocol). Um coletor — otel-collector — para receber, processar e exportar telemetria para qualquer backend. Os fornecedores competem em análise e visualização, não em lock-in de instrumentação.

O Estado do OTel em 2026

A aposta valeu a pena. O OpenTelemetry está implantado em produção no Google, Microsoft, Shopify, Uber e milhares de outras organizações. Todos os principais backends de observabilidade — Datadog, Grafana, Elastic, Honeycomb, Dynatrace, New Relic, Splunk — aceitam OTLP nativamente. A CNCF relata que o OpenTelemetry está em uso em 83% das empresas da Fortune 500 de alguma forma. Isso não é mais um projeto de nicho. Isso é infraestrutura.

Os SDKs Go, Java, Python e JavaScript são estáveis e bem mantidos. A auto-instrumentação para frameworks populares — Django, Express, Spring Boot, Rails — funciona de forma confiável. Você pode adicionar uma única dependência, definir algumas variáveis de ambiente e ter rastreamentos fluindo para seu backend sem tocar no código da aplicação. Para projetos novos, este é o ponto de partida óbvio.

O Que Realmente Está Funcionando

Rastreamentos são a parte mais forte da história do OTel. A especificação de rastreamento é madura. Os SDKs são estáveis. A auto-instrumentação para HTTP, chamadas de banco de dados e sistemas de mensagens cobre as necessidades de instrumentação mais comuns. Se você está começando com OTel hoje, comece aqui.

O otel-collector é poderoso e comprovado em produção. Ele pode receber telemetria de dezenas de fontes, aplicar transformações, filtrar ruídos e distribuir para múltiplos backends simultaneamente. Equipes que executam ambientes multi-nuvem complexos usam o coletor como uma camada de roteamento de telemetria — exporte tudo para o coletor, deixe o coletor lidar com o roteamento do backend.

O ecossistema também amadureceu em torno do coletor. Receivers e exporters contrib cobrem a maioria das fontes de dados empresariais. O operador para Kubernetes é sólido. Distribuições do coletor por fornecedores (como o AWS Distro for OpenTelemetry ou o Grafana Agent) fornecem builds testados e suportados com exporters específicos do fornecedor pré-configurados.

O Que Ainda é Difícil

Logs só recentemente se estabilizaram na especificação do OTel. O sinal de log ficou para trás em relação a rastreamentos e métricas significativamente, e embora agora esteja estável, o ecossistema ainda não alcançou totalmente. Correlacionar logs com rastreamentos usando TraceId e SpanId — que é o objetivo principal — ainda requer configuração deliberada na maioria dos frameworks. Funciona, mas ainda não é esforço zero.

As convenções semânticas de métricas são inconsistentes entre linguagens. Uma métrica nomeada de uma forma no SDK Java é nomeada de forma ligeiramente diferente no SDK Python. Isso está sendo resolvido, mas lentamente. Equipes que constroem painéis entre linguagens encontram esse atrito.

A configuração do coletor é complexa. A configuração YAML do otel-collector — receivers, processors, exporters, pipelines — é flexível, mas verbosa. À medida que as topologias crescem, você acaba com arquivos YAML que são genuinamente difíceis de raciocinar. Ainda não há uma grande solução aqui. Algumas equipes usam jsonnet ou cue para gerar configurações do coletor. Outras escrevem ferramentas de gerenciamento de configuração. É um problema solucionável, mas é trabalho operacional real.

A amostragem baseada em cauda é poderosa, mas operacionalmente pesada. A amostragem baseada em cabeça (tomar a decisão de amostragem no início de um rastreamento) é simples e sem estado. A amostragem baseada em cauda (tomar a decisão de amostragem depois de ver o rastreamento completo) permite manter 100% dos rastreamentos de erro e rastreamentos lentos enquanto descarta os rotineiros — mas requer infraestrutura com estado. O processador tailsampling no OTel Collector funciona, mas requer uma arquitetura de implantação cuidadosa para garantir que todos os spans de um determinado rastreamento caiam na mesma instância do coletor.

O Problema de Cardinalidade Que o OTel Não Resolveu

O OpenTelemetry facilita a adição de atributos à sua telemetria. Isso é um recurso. Também é uma armadilha. Adicionar atributos de alta cardinalidade — IDs de usuário, IDs de requisição, tokens de sessão — a métricas é um erro clássico que causa explosões de custo em backends que cobram por série de métrica (que é a maioria deles).

O OTel não protege você disso. Ele encaminha fielmente quaisquer atributos que você anexar. A explosão de cardinalidade é um problema do backend, mas o OTel é o mecanismo pelo qual você a cria. Equipes adotando OTel precisam entender isso cedo: a governança de cardinalidade de métricas não é opcional, é higiene operacional. Use atributos de alta cardinalidade em spans e logs, onde eles pertencem. Mantenha as dimensões das métricas baixas e deliberadamente limitadas.

O Quarto Sinal: Profiling

O OpenTelemetry está trabalhando em um quarto sinal de observabilidade: profiling contínuo. Dados de profiling — gráficos de chama de CPU, rastreamentos de alocação de memória — historicamente viveram em ferramentas separadas (pprof, async-profiler, py-spy) sem um formato padrão ou correlação com os outros três sinais.

O sinal de profiling do OTel ainda é experimental, mas Grafana, Elastic e vários outros fornecedores já estão apostando nele. O objetivo é o mesmo que para os outros sinais: um formato padrão, um protocolo de rede padrão, correlação com rastreamentos. Quando se estabilizar, fechará a última grande lacuna na história de observabilidade do OTel.

Conselhos Práticos para Equipes Adotando OTel Hoje

• Comece com rastreamentos. O sinal de rastreamento é o mais maduro. Use auto-instrumentação primeiro — não instrumente manualmente antes de ver o que a auto-instrumentação lhe dá.
• Escolha seu backend antes de configurar o coletor. A configuração do pipeline do coletor depende de para onde você está exportando. Não construa uma topologia de coletor complexa antes de conhecer seu backend. Um único exportador é suficiente para começar.
• Não crie uma topologia de coletor personalizada prematuramente. Os endpoints OTLP gerenciados da maioria dos fornecedores são bons o suficiente para a maioria das equipes. O coletor adiciona sobrecarga operacional. Adicione-o quando precisar de distribuição, filtragem ou enriquecimento — não antes.
• Entenda cardinalidade antes de adicionar atributos de métrica. Tenha uma conversa com quem é responsável pela conta de observabilidade antes de enviar sua primeira métrica personalizada. Defina seu conjunto de rótulos permitidos explicitamente.
• Use os SDKs, não a API diretamente. A API do OTel é o contrato estável; o SDK é a implementação. No código da aplicação, dependa do SDK. Dependa diretamente da API apenas se estiver escrevendo uma biblioteca que não deve forçar uma escolha de SDK nos consumidores.

A Guerra Está Vencida. O Trabalho Não Está Terminado.

O OpenTelemetry alcançou algo genuinamente raro em software de infraestrutura: matou o problema de lock-in de instrumentação. Os fornecedores competem na qualidade de sua análise, suas linguagens de consulta, suas alertas, sua UX — não em prendê-lo em seu SDK. Esse é um mundo melhor.

Mas "o padrão venceu" é o começo da história, não o fim. A parte difícil — convenções consistentes entre linguagens, configuração acessível do coletor, logs estáveis, governança de cardinalidade, profiling — ainda está sendo trabalhada. Equipes adotando OTel hoje estão fazendo isso em um ecossistema maduro, mas ainda em evolução. Tudo bem. A base é sólida. Construa sobre ela deliberadamente.