O que é OpenTelemetry e por que ele virou padrão na observabilidade?
Durante anos, instrumentar uma aplicação significava usar o agente e as bibliotecas de um fornecedor específico, e trocar de ferramenta exigia refazer a instrumentação. O OpenTelemetry nasceu para resolver esse problema: separar a geração dos dados de telemetria da ferramenta que os analisa.
O que é
OpenTelemetry, conhecido como OTel, é um projeto de código aberto da Cloud Native Computing Foundation (CNCF). Ele define especificações, APIs, kits de desenvolvimento (SDKs) e ferramentas para gerar, coletar e exportar traces, métricas e logs. Surgiu em 2019 da fusão de dois projetos anteriores, OpenTracing e OpenCensus, e se tornou um dos projetos mais ativos da CNCF.
O OpenTelemetry não é uma ferramenta de análise nem um banco de dados: ele produz e transporta a telemetria. Os dados seguem para a plataforma escolhida, comercial ou de código aberto.
Os componentes
- API e SDKs: bibliotecas por linguagem, como Java, .NET, Python, Go e JavaScript, para criar spans, métricas e logs no código.
- Instrumentação automática: agentes e bibliotecas que capturam chamadas HTTP, consultas a banco e mensagens de fila sem alterar o código da aplicação.
- OTLP: o protocolo padrão de transporte da telemetria, sobre gRPC ou HTTP.
- Collector: serviço intermediário que recebe, processa e exporta os dados.
- Convenções semânticas: nomes padronizados para atributos, como service.name para o serviço e http.response.status_code para o código de resposta, o que permite correlacionar dados de origens diferentes.
O papel do Collector
O Collector é o ponto central de uma arquitetura com OpenTelemetry. Ele é organizado em receivers, que recebem dados em vários formatos; processors, que transformam esses dados; e exporters, que os enviam a um ou mais destinos.
É nele que se aplicam decisões importantes: remover dados sensíveis antes que saiam da rede, acrescentar atributos como ambiente e região, agrupar envios, fazer amostragem de traces e enviar a mesma telemetria para duas ferramentas ao mesmo tempo, o que facilita migrações e comparações.
Por que adotar
O principal ganho é a independência: a instrumentação feita uma vez continua válida se a empresa trocar de plataforma de observabilidade. Os grandes fornecedores do mercado aceitam dados no formato OpenTelemetry, assim como ferramentas de código aberto, entre elas SigNoz, Jaeger e Prometheus.
Há também ganho de consistência. Com as convenções semânticas, serviços escritos em linguagens diferentes compartilham os mesmos nomes de atributos e o mesmo identificador de trace, o que permite navegar de um alerta ao trace e do trace aos logs daquela requisição.
Cuidados na adoção
- Maturidade desigual: o nível de estabilidade varia por linguagem e por tipo de sinal. Verifique o status do SDK da sua linguagem antes de padronizar.
- Custo: a instrumentação automática gera muito dado. Defina amostragem e retenção desde o início.
- Dados sensíveis: atributos podem capturar URLs com parâmetros, cabeçalhos e consultas SQL com dados pessoais. Configure filtros no SDK ou no Collector.
- Nomes padronizados: sem service.name e ambiente definidos de forma consistente, a correlação se perde.
- Operação do Collector: em produção, ele é um componente crítico, que precisa de monitoramento, capacidade e alta disponibilidade.
OpenTelemetry é o padrão aberto da CNCF para gerar e transportar logs, métricas e traces. Separa a instrumentação da ferramenta de análise, padroniza nomes e concentra no Collector o filtro, o enriquecimento e o roteamento dos dados. Exige atenção a maturidade, custo e dados sensíveis.
Este conteúdo foi útil?
Revisão técnica VIPER IT — última atualização em 10 de outubro de 2026.