OpenTelemetry: o que é, como funciona e como implementar
Autor: Pedro Tebaldi PM do KeepGreen
Revisão técnica: Ednilson Correa SREDurante anos, instrumentar uma aplicação para observabilidade significava escolher um fornecedor e aceitar o lock-in. Ou seja, o agente de APM do fornecedor A não conversava com o backend do fornecedor B. Migrar de plataforma, portanto, exigia reescrever toda a instrumentação. Pior: quem trabalhava com múltiplas linguagens convivia com padrões de coleta incompatíveis entre si.
Contra exatamente esse cenário nasceu o OpenTelemetry. Trata-se de um projeto open source mantido pela CNCF, a Cloud Native Computing Foundation. Seu padrão é único e agnóstico de vendor: instrumenta a aplicação e exporta métricas, logs e traces para qualquer backend de observabilidade.
Neste guia técnico, você vai entender o que é OpenTelemetry, como funciona sua arquitetura, quais são os componentes principais e como implementar em projetos reais.
O que é OpenTelemetry?
OpenTelemetry (abreviado OTel) é um framework open source de observabilidade. Ele reúne APIs, SDKs, agentes e um protocolo de exportação padronizados para coletar telemetria de aplicações e infraestrutura. Nascido em 2019 da fusão entre OpenTracing e OpenCensus, o projeto logo virou o padrão de facto da indústria.
Na prática, a proposta central é simples: uma aplicação instrumentada com OpenTelemetry exporta seus dados para Datadog, Prometheus, Grafana Tempo, Jaeger, Elastic, New Relic ou qualquer outro backend compatível. E faz isso sem alterar o código de instrumentação. Dessa forma, o vendor lock-in desaparece e a escolha da plataforma fica independente da estratégia de instrumentação.
Quem mantém o projeto é a CNCF, a mesma fundação por trás de Kubernetes e Prometheus. Somado a isso, contribuem com ele Google, Microsoft, AWS, Datadog, New Relic e dezenas de outras empresas. A lista de fornecedores do projeto reunia 105 organizações em 28 de agosto de 2026, e 102 delas consomem OTLP nativamente. Há uma ressalva, porém: o próprio site congelou novas inclusões em agosto de 2026, portanto esse número é piso, não teto. Em clusters de containers, o guia de OpenTelemetry no Kubernetes mostra como implantar o padrão com Collector e Operator.
Os três pilares do OpenTelemetry
Três tipos de dados de telemetria compõem a observabilidade moderna, e o OpenTelemetry cobre todos eles.
Traces
Traces distribuídos foram o primeiro pilar que o OpenTelemetry implementou, herdado diretamente do OpenTracing. Um trace representa, em síntese, a jornada completa de uma requisição por todos os serviços de um sistema distribuído.
Por todos os serviços que a requisição atravessa, o OTel propaga automaticamente o trace_id, um identificador único. O transporte varia: headers HTTP, com o W3C TraceContext como padrão, mensagens de fila ou gRPC. Assim, o backend correlaciona traces de serviços e linguagens diferentes em uma única visão coerente.
Métricas
No OpenTelemetry, a API de métricas define instrumentos padronizados: Counter (valor que só cresce), Gauge (valor que varia), Histogram (distribuição de valores para percentis) e UpDownCounter. Já a exportação aceita formatos compatíveis com Prometheus, OTLP e outros backends.
Além dos instrumentos, o OpenTelemetry define convenções semânticas: nomes e atributos padronizados para métricas comuns de serviços HTTP, bancos de dados, mensageria e runtimes. Por isso, dashboards e alertas se tornam reutilizáveis entre serviços e equipes.
Cada instrumento, porém, chega ao backend de um jeito. O guia de métricas de OpenTelemetry mostra os três em código e o que muda no nome ao exportar para o Prometheus.
Logs
Logs formam o terceiro pilar, adicionado mais recentemente. Aqui o OTel não substitui as bibliotecas existentes, como Log4j, SLF4J ou Winston. Em vez disso, ele as instrumenta automaticamente para injetar trace_id e span_id do contexto atual em cada linha de log.
Justamente essa injeção automática viabiliza a correlação entre os três pilares. Do alerta de métrica você chega ao trace afetado, e do trace aos logs exatos daquele trace, sem nenhuma busca manual.
Arquitetura do OpenTelemetry
SDK e instrumentação automática
Todas as principais linguagens têm SDK do OpenTelemetry: Java, Python, Go, JavaScript/Node.js, .NET, Ruby, PHP e Rust, entre outras. Cada SDK inclui instrumentação automática para as bibliotecas mais populares, como frameworks web (Express, Django, Spring), clientes HTTP e drivers de banco. Dessa forma, esses componentes geram spans, métricas e logs sem exigir mudança no código da aplicação.
Para casos específicos, a API permite adicionar instrumentação manual: criar spans customizados, adicionar atributos de contexto de negócio e registrar eventos relevantes para o domínio da aplicação.
OpenTelemetry Collector
OTel Collector é um componente opcional, embora altamente recomendado: um processo separado que recebe a telemetria das aplicações, processa (filtra, transforma, agrega) e exporta para um ou múltiplos backends.
Sua vantagem está em desacoplar as aplicações dos backends de observabilidade. Quando a organização troca Datadog por Elastic, basta reconfigurar o Collector: as aplicações, portanto, permanecem inalteradas. Além disso, ele acrescenta processamento, como sampling de traces ou enriquecimento de atributos, sem tocar no código.
Quatro blocos formam a configuração do Collector: receivers, processors, exporters e service. Os três primeiros apenas declaram componentes. Quem decide o que roda, porém, é o service: um exporter declarado e ausente dali não recebe nada.
No laboratório da OpServices, o arquivo abaixo subiu com o Collector 0.139.0, em 28 de agosto de 2026. Ele monta um pipeline separado para cada pilar, isto é, um para traces, um para métricas e um para logs.
Dentro de processors, a ordem não é estética. O memory_limiter vem primeiro porque precisa recusar o lote antes de ele ocupar memória. Já o batch fica por último, para agrupar somente o que sobreviveu aos filtros. Inverter os dois faz o Collector gastar CPU agrupando dado que será descartado em seguida.
Na subida, o Collector registra cada componente que ativou. Esta é a saída real do laboratório, com o objeto resource repetido reduzido a reticências:
A primeira linha devolve os limites que o memory_limiter leu do arquivo: 512 MiB de teto e 128 MiB de folga. Em seguida, as duas linhas de receiver confirmam as portas 4317 e 4318 abertas. Por fim, Everything is ready marca os três pipelines no ar. Ademais, cada componente tem sua referência na documentação de configuração do Collector.
Protocolo OTLP
OTLP (OpenTelemetry Protocol) é o protocolo de transporte que o OTel define para o envio de telemetria. Ele aceita gRPC e HTTP/Protobuf. Como formato nativo de exportação do Collector, chega direto aos principais backends de observabilidade. A especificação do OTLP, por sua vez, fixa as portas padrão: 4317 para gRPC e 4318 para HTTP.
Ebook: Como sobreviver à fatura cloud?
Nosso framework, Observability Maturity Index, mede a maturidade das operações em nuvem das empresas. Você encontrará: os quatro perfis de empresas, as métricas que você deveria estar medindo, um checklist de avaliação e um plano de ação para 90 dias.
Só o e-mail. Sem spam, e seus dados protegidos pela LGPD.
OpenTelemetry e a correlação entre pilares
Entre os diferenciais técnicos do OpenTelemetry, o mais importante é a propagação automática de contexto, que viabiliza a correlação entre os três pilares. O mecanismo funciona assim: quando a requisição chega ao serviço, o SDK extrai o trace_id do header. Em seguida, cria um span para aquela operação e guarda o contexto, trace_id mais span_id, num objeto acessível a toda a thread ou coroutine.
Quando a aplicação escreve um log ou registra uma métrica durante aquele processamento, o SDK injeta trace_id e span_id nos dados. O resultado aparece na plataforma de observabilidade: logs, métricas e traces da mesma requisição compartilham o identificador. Portanto, navegar entre pilares deixa de exigir busca.
Daí vem a redução do MTTD e do tempo de diagnóstico em incidentes. Do alerta de métrica ao trace afetado, e deste ao log de erro, o caminho leva segundos e dispensa busca manual entre ferramentas separadas.
Como implementar OpenTelemetry na prática
Em qualquer linguagem, a implementação segue quatro etapas.
Primeiro, adicione ao projeto as dependências do SDK e das instrumentações automáticas. Na maioria das linguagens, isso já basta para gerar traces e métricas das bibliotecas populares, sem alterar o código da aplicação.
Em seguida, configure o exportador, que define para onde os dados vão. Em desenvolvimento, o padrão é o exportador OTLP apontando para um Collector local. Já em produção, o Collector roteia para múltiplos backends.
Esse passo, porém, esconde uma armadilha que só aparece no dashboard. Pontos no nome da métrica valem no OTLP, mas não no Prometheus. Na exportação, portanto, o Collector troca cada ponto por sublinhado e ainda acrescenta a unidade ao nome.
No laboratório, a instrumentação automática do Flask emitiu http.server.duration com unidade ms. Foi assim que a mesma série chegou ao endpoint do exporter, depois de 150 requisições em cada serviço:
Veja o resultado: o nome virou http_server_duration_milliseconds. Um alerta escrito com o nome OTLP, portanto, não casa com série nenhuma. Já o rótulo deployment_environment_name comprova que o processor resource agiu antes do exporter.
Como referência, valem também os números do bloco. Cada série somou 150 requisições: 153 ms no serviço de estoque, que consulta por índice, contra 6.314 ms no de produtos, que varre a tabela inteira. Em resumo, são 1,02 ms contra 42,1 ms por requisição, medidos pelo próprio pipeline de métricas.
Depois disso, valide a instrumentação automática e acrescente spans customizados. Eles cobrem as operações de negócio críticas que passam despercebidas, como chamadas a APIs externas específicas ou operações de domínio relevantes para o diagnóstico.
Por fim, adote as convenções semânticas nos atributos customizados. Assim, os dados da sua aplicação nascem compatíveis com os dashboards e alertas padronizados da organização.
Para aprofundar, toda a referência técnica está em opentelemetry.io/docs, com guias de início rápido por linguagem e a especificação completa das convenções semânticas. Para entender como o OTel se encaixa no ecossistema cloud-native, a página do projeto na CNCF contextualiza maturidade e adoção.
Logs, métricas e traces unificados para diagnóstico em profundidade.
Instrumentamos aplicações corporativas com OpenTelemetry para correlacionar eventos e acelerar a análise de causa raiz em produção.
Conclusão
Por anos, a fragmentação da instrumentação bloqueou a adoção de observabilidade em larga escala, e o OpenTelemetry resolveu esse problema. Ao padronizar APIs, SDKs e o protocolo de exportação, ele eliminou o vendor lock-in. Hoje dá para instrumentar uma aplicação uma vez e exportá-la para qualquer backend.
Para times de SRE e DevOps, o OpenTelemetry é hoje o ponto de partida recomendado em qualquer estratégia de observabilidade. Ele une métricas, logs e traces num pipeline coeso, com correlação automática. Se quiser estruturar essa instrumentação no seu ambiente, fale com nossos especialistas.
Perguntas Frequentes
O que é OpenTelemetry?
Qual a diferença entre OpenTelemetry e OpenTracing?
O que é o OpenTelemetry Collector?
OpenTelemetry substitui o Prometheus?
Como OpenTelemetry correlaciona logs, métricas e traces?
trace_id único por toda a execução de uma requisição. Quando a aplicação escreve um log ou registra uma métrica durante aquele processamento, o SDK injeta automaticamente o trace_id nos dados. Isso faz com que logs, métricas e traces da mesma requisição compartilhem o mesmo identificador — permitindo navegar entre os três pilares diretamente na plataforma de observabilidade sem busca manual.
