OpenTelemetry: o padrão moderno para observabilidade completa

O que é OpenTelemetry e por que surgiu

OpenTelemetry (OTel) é um projeto open-source da CNCF que nasceu da fusão entre OpenTracing e OpenCensus em 2019, dois padrões concorrentes de instrumentação que fragmentavam o ecossistema de observabilidade. Antes do OTel, times precisavam escolher entre instrumentações incompatíveis ou manter múltiplas bibliotecas para diferentes backends como Jaeger, Zipkin, Datadog e New Relic. A proposta do OpenTelemetry é fornecer uma API e SDK unificados para coletar logs, métricas e traces, com exporters para qualquer backend, eliminando o lock-in em fornecedores. A especificação OTel é mantida pela comunidade com adoção de empresas como Google, Microsoft, AWS, Datadog e Splunk, tornando-a o padrão de facto para observabilidade em sistemas modernos.

Os três pilares — logs, métricas e traces com OTel

O OpenTelemetry cobre os três pilares de observabilidade com APIs e SDKs padronizados para cada um. Traces representam o fluxo de execução de uma requisição através de serviços, com spans hierárquicos e propagação de contexto. Métricas são medidas numéricas agregadas ao longo do tempo — counters, gauges, histogramas — exportadas para backends como Prometheus ou Datadog. Logs no contexto do OTel são enriquecidos com Trace ID e Span ID, permitindo correlação direta entre uma entrada de log e o trace que a gerou. A correlação automática entre os três sinais é uma das maiores vantagens do OTel em relação a instrumentações separadas, onde a correlação era manual e inconsistente.

SDK e API — como instrumentar aplicações

O OpenTelemetry diferencia entre API e SDK: a API define as interfaces para criar spans, métricas e logs, enquanto o SDK fornece a implementação completa com processadores, exporters e samplers. Código de biblioteca deve depender apenas da API OTel, para não forçar uma implementação de SDK específica nos consumidores. Aplicações finais dependem do SDK e configuram exporters, sampling e processadores de acordo com a infraestrutura de observabilidade disponível. A inicialização típica envolve criar um TracerProvider, um MeterProvider e um LoggerProvider configurados com o exporter desejado — OTLP, Jaeger, Zipkin, Console — e registrá-los como providers globais para que a instrumentação automática os use.

Collector — recebendo e exportando telemetria

O OpenTelemetry Collector é um componente intermediário que recebe telemetria de aplicações, processa e encaminha para um ou múltiplos backends. O Collector tem três estágios: receivers que aceitam dados em diferentes formatos (OTLP, Jaeger, Zipkin, Prometheus), processors que transformam e filtram os dados (batch, filter, attribute, sampling), e exporters que enviam para backends como Jaeger, Prometheus, Datadog, New Relic e Elasticsearch. Usar o Collector desacopla completamente a configuração de backends do código de aplicação: para mudar de Jaeger para Datadog, basta reconfigurar o Collector, sem alterar nenhum serviço. O Collector também suporta pipelines paralelas, enviando o mesmo trace para múltiplos backends simultaneamente.

Auto-instrumentação — sem mudar código

A auto-instrumentação do OpenTelemetry usa agentes e bibliotecas de instrumentação que interceptam chamadas de frameworks e bibliotecas populares sem modificar o código da aplicação. Para Java, o agente OTel é um JAR que se anexa à JVM via argumento -javaagent e instrumenta automaticamente Spring Boot, JDBC, Kafka, gRPC e dezenas de outras bibliotecas. Para Node.js, o pacote @opentelemetry/auto-instrumentations-node instrumenta Express, HTTP, gRPC, MongoDB, Redis e pg. Para Python, opentelemetry-instrument funciona como wrapper de linha de comando. Auto-instrumentação cobre a maioria das chamadas de infraestrutura, e instrumentação manual adiciona contexto de negócio específico — como IDs de pedidos e eventos de domínio.

Configurando exporters — Jaeger, Prometheus, OTLP

Exporters são os componentes que traduzem a telemetria coletada pelo SDK para o formato esperado por cada backend. O exporter OTLP (OpenTelemetry Protocol) é o padrão recomendado, enviando dados em formato Protobuf sobre HTTP ou gRPC para o OTel Collector ou backends que suportam OTLP nativamente como Jaeger, Grafana Cloud e Datadog. Para métricas com Prometheus, o exporter expõe um endpoint HTTP /metrics que o Prometheus faz scraping periodicamente. Em desenvolvimento, o exporter Console imprime traces e métricas no terminal para validação rápida sem infraestrutura de backend. Múltiplos exporters podem ser configurados simultaneamente via exporter composto, útil para enviar traces ao Jaeger e métricas ao Prometheus ao mesmo tempo.

Context propagation — passando trace ID entre serviços

Context propagation é o mecanismo pelo qual o OpenTelemetry passa informações de trace entre serviços, garantindo que spans de diferentes processos sejam conectados no mesmo trace. O OTel usa propagators para serializar e deserializar o contexto: o propagator W3C TraceContext é o padrão, usando os headers traceparent e tracestate em requisições HTTP. Para comunicação via Kafka, o contexto é injetado nas propriedades da mensagem pelo produtor e extraído pelo consumidor. O OTel SDK gerencia automaticamente a propagação quando se usa auto-instrumentação, mas em código customizado é necessário chamar explicitamente propagator.inject() e propagator.extract(). Propagação incorreta resulta em traces fragmentados que não mostram o caminho completo da requisição.

OpenTelemetry em .NET, Java, Node.js e Python

O suporte do OpenTelemetry é consistente entre as principais linguagens, com maturidade variando por ecossistema. Em .NET, o pacote OpenTelemetry do NuGet integra com o sistema de Activity do runtime, aproveitando instrumentação nativa do ASP.NET Core, Entity Framework e HttpClient. Em Java, a instrumentação manual usa Tracer.spanBuilder() da API OTel, e a auto-instrumentação via agente JAR cobre Spring, Hibernate e frameworks REST. Em Node.js, o SDK é configurado programaticamente antes do carregamento da aplicação, com suporte a ESM e CJS. Em Python, a API é similar às outras linguagens com decorators para instrumentação de funções. A paridade de funcionalidades entre linguagens garante que sistemas poliglotas tenham observabilidade consistente.

Custo e volume de telemetria em produção

Em sistemas de alto tráfego, o volume de telemetria gerado pelo OpenTelemetry pode ser significativo — um serviço que processa 10.000 requisições por segundo com média de 10 spans por requisição gera 100.000 spans por segundo, o que impacta diretamente o custo de storage e processamento no backend. Estratégias de redução incluem: head-based sampling para traçar apenas uma fração das requisições normais, tail-based sampling para garantir que erros sejam sempre capturados, e filtragem de spans de baixo valor no OTel Collector antes de exportar. Métricas têm custo controlado pela cardinalidade das labels. Logs são seletivamente enriquecidos com Trace ID apenas quando o trace está amostrado, evitando campos desnecessários em 99% dos logs.

Conclusão

OpenTelemetry consolidou o ecossistema de observabilidade ao fornecer uma API e SDK únicos para logs, métricas e traces com suporte às principais linguagens e backends. A separação entre API e SDK protege bibliotecas de lock-in e permite que aplicações escolham livremente seus backends de observabilidade. O OTel Collector centraliza o roteamento de telemetria, tornando mudanças de backend transparentes para as aplicações. Auto-instrumentação elimina a maior parte do trabalho de instrumentação, reservando o esforço manual para contexto de negócio que realmente importa. Adotar OpenTelemetry desde o início de um projeto é uma das melhores decisões de longo prazo para visibilidade operacional. Continue em: Fundamentos obrigatórios antes de produção.