Observabilidade com OpenTelemetry: logs, métricas e traces em um padrão só

Três da manhã. Um usuário reclama que o checkout está lento. Você abre o Kibana para ver os logs da aplicação, o Grafana para olhar o uso de CPU e uma terceira ferramenta para tentar achar onde a requisição travou. Três telas, três formas diferentes de filtrar, três relógios que não batem exatamente. Quando você finalmente junta as peças, já se passaram quarenta minutos.

Esse cenário não é falta de ferramenta. É excesso delas, sem costura entre uma e outra. Segundo levantamento publicado pela CNCF em maio de 2026, 46,7% das organizações ainda operam de duas a três ferramentas de observabilidade em paralelo, e apenas 7,4% conseguiram unificar tudo em uma só visão.

O padrão que está resolvendo isso se chama OpenTelemetry. Em 21 de maio de 2026 ele se tornou projeto graduado da CNCF, o mesmo selo de maturidade que Kubernetes e Prometheus carregam. Este artigo explica o que ele é, por que virou padrão de mercado e como colocar um serviço Java instrumentado no ar sem escrever uma linha de código.

Monitoramento e observabilidade não são a mesma coisa

Vale separar os dois termos, porque eles são usados como sinônimos e não são.

Monitoramento responde perguntas que você já sabia fazer: a CPU passou de 80%? O serviço respondeu ao health check? Você define o alerta antes, e ele dispara quando a condição acontece.

Observabilidade é a capacidade de responder perguntas que você não previu. Por que só os pedidos com cupom de desconto estão lentos, e só para usuários de um estado específico? Ninguém cria um alerta para isso de antemão. Você precisa que o sistema tenha deixado rastro suficiente para investigar depois.

Esse rastro se organiza em três sinais.

Logs

Registros de eventos discretos, com carimbo de tempo. “Pedido 4821 falhou na validação do CPF.” Ótimos para entender o que aconteceu em um ponto específico, ruins para enxergar tendência.

Métricas

Valores numéricos agregados ao longo do tempo. “Média de 340ms de latência no endpoint de checkout nos últimos 5 minutos.” Ótimas para ver tendência e disparar alerta, mas não dizem qual requisição foi lenta.

Traces

O caminho completo de uma requisição atravessando os serviços. O trace mostra que a requisição entrou na API em 12ms, chamou o serviço de pagamento que levou 890ms, e dentro dele uma consulta ao banco consumiu 850ms. É o sinal que responde “onde exatamente o tempo foi embora”.

Os três se completam: a métrica te avisa que algo piorou, o trace mostra onde, e o log explica o que houve naquele ponto. O problema nunca foi ter os três. Foi cada um viver em uma ferramenta diferente, com formatos incompatíveis.

O que o OpenTelemetry resolve

Antes dele, instrumentar uma aplicação significava escolher um fornecedor e escrever código acoplado a ele. Trocar de ferramenta depois exigia reinstrumentar tudo. Era um custo alto o bastante para prender times a decisões tomadas anos antes.

O OpenTelemetry quebra esse acoplamento fornecendo uma camada única: uma API, um conjunto de SDKs, um agente coletor e um protocolo de transporte, o OTLP. Sua aplicação passa a falar OTel, e para qual backend os dados vão vira configuração, não reescrita de código.

Os números da graduação ajudam a dimensionar a adoção: mais de 12 mil contribuidores de mais de 2.800 empresas, segunda maior velocidade de projeto entre os mais de 240 projetos da CNCF, atrás apenas do Kubernetes. Nos doze meses anteriores ao anúncio, o pacote da API JavaScript passou de 1,36 bilhão de downloads e o da API Python de 1,3 bilhão, ambos batendo recorde mensal em abril de 2026.

Nas palavras de Chris Aniszczyk, CTO da CNCF, no anúncio oficial:

“A graduação do OpenTelemetry o consolida como o padrão essencial e unificado de observabilidade.”

Sobre maturidade dos sinais: métricas, logs e traces estão estáveis. O quarto sinal, continuous profiling, foi promovido a alpha recentemente — ou seja, existe e está avançando, mas ainda não é terreno para produção.

Mão na massa: instrumentando uma aplicação Java sem tocar no código

Aqui está a parte que costuma surpreender quem está começando. Para uma aplicação Java, você não precisa escrever nada para ter traces e métricas. O agente faz a instrumentação automática em bibliotecas conhecidas: servidores HTTP, clientes de banco, filas.

Baixe o agente:

curl -L -O https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/latest/download/opentelemetry-javaagent.jar

E suba a aplicação com ele anexado:

java -javaagent:path/to/opentelemetry-javaagent.jar \
     -Dotel.service.name=your-service-name \
     -jar myapp.jar

Se preferir não mexer na linha de comando, o mesmo resultado sai por variáveis de ambiente, o que costuma ser mais prático dentro de um container:

export JAVA_TOOL_OPTIONS="-javaagent:path/to/opentelemetry-javaagent.jar"
export OTEL_SERVICE_NAME="your-service-name"
java -jar myapp.jar

Para dizer para onde os dados vão, o padrão define variáveis de ambiente que valem para qualquer linguagem:

# destino dos dados; a porta muda conforme o protocolo
export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4318"

# grpc, http/protobuf ou http/json
export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf"

Os padrões do próprio protocolo são http://localhost:4317 para gRPC e http://localhost:4318 para HTTP. Guarde essas duas portas: quando os dados não aparecerem no backend, a causa costuma ser protocolo e porta que não combinam.

Repare no ganho didático: o mesmo par de variáveis funciona se amanhã você trocar o destino. A aplicação não sabe nem se importa com quem está do outro lado.

Onde os dados vão parar

O OpenTelemetry coleta e transporta, mas não armazena nem desenha gráfico. Ele entrega para um backend, e é aí que entra a stack que você já conhece.

A Elastic, por exemplo, se posiciona como OTel-first: ingere dados OpenTelemetry nativamente, sem camada de conversão, e mantém a EDOT (Elastic Distributions of OpenTelemetry), uma distribuição própria do coletor com suporte e correções fora do ciclo do projeto upstream. Na prática, isso significa que o Elasticsearch e o Kibana passam a receber traces e métricas pelo mesmo caminho por onde já recebiam logs.

E é exatamente esse o ponto que fecha o ciclo do problema lá do começo: não são três stacks, é uma só, alimentada por um padrão aberto.

Erros comuns de quem está começando

Achar que observabilidade é só coletar mais log. Log sem trace não responde onde o tempo foi gasto. Aumentar volume de log costuma aumentar a conta sem aumentar a capacidade de investigar.
Instrumentar tudo manualmente de primeira. Comece com o agente automático. Só escreva span manual depois, para a lógica de negócio que o agente não tem como conhecer.
Esquecer de nomear o serviço. Sem OTEL_SERVICE_NAME, seus dados chegam ao backend sem identidade e você perde a capacidade de separar um serviço do outro.
Confundir o protocolo com a porta. gRPC em 4317, HTTP em 4318. Apontar HTTP para a porta do gRPC falha em silêncio, sem erro visível na aplicação.
Enviar 100% dos traces em produção. Em volume alto isso fica caro rápido. Amostragem existe justamente para isso, e deve entrar na conta antes de ligar em produção, não depois da fatura.
Tratar profiling como pronto. É o sinal mais novo, ainda em alpha. Vale estudar, não vale apoiar operação em cima dele agora.

Por onde começar

Um roteiro curto que cabe em uma tarde. Suba uma aplicação Java simples com um endpoint que consulta um banco. Anexe o agente e aponte o OTEL_EXPORTER_OTLP_ENDPOINT para um coletor local. Faça algumas requisições e abra o trace de uma delas.

O momento que ensina de verdade é ver, no mesmo trace, a requisição HTTP e a consulta ao banco aninhada dentro dela, cada uma com sua duração. Depois disso, a diferença entre log, métrica e trace deixa de ser definição decorada e vira coisa que você enxerga.

Se você está estudando DevOps agora, vale saber que o OpenTelemetry deixou de ser diferencial e virou vocabulário básico. A ferramenta de visualização muda de emprego para emprego. O padrão que alimenta ela, cada vez menos.