OpenTelemetry está virando o USB da observabilidade.

TL;DR

padrão aberto de observabilidade que faltava entre o código e o backend chama-se OpenTelemetry. Jardim murado de agents, SDKs e formatos proprietários cobra juros mensais em manutenção, lock-in e dashboards que ninguém sabe se pode confiar. Um único SDK por linguagem cobre traces, métricas e logs. Um único coletor roteia para qualquer backend. A pergunta em 2026 não é qual backend contratar — é qual parte da instrumentação proprietária ainda precisa ser cortada. A analogia é física, não retórica: o USB acabou com a bagunça de cabo e driver proprietário. OpenTelemetry está fazendo o mesmo com telemetria.

• O padrão aberto de observabilidade entrega SDK único por linguagem cobrindo traces, métricas e logs sem amarrar código a vendor. OpenTelemetry é o nome concreto desse padrão.
• O lock-in de observabilidade é o custo invisível: 8% a 15% do tempo de engenharia gasto mantendo integração com agent proprietário, mais 12 a 24 meses projetados de custo de saída. OpenTelemetry elimina esse lock-in por exportação.
• O OpenTelemetry Collector transforma SDK em plataforma: enriquece, amostra, roteia e exporta para múltiplos backends sem reescrever a instrumentação.
• Migração para OpenTelemetry é projeto de engenharia com payback de 6 a 12 meses — não é troca de fornecedor, é eliminação de dívida operacional recorrente.
• Em 2026 o critério de gestão é “qual parte da instrumentação proprietária ainda preciso cortar”, não “qual backend OpenTelemetry escolher”.

~ 13 min de leitura · 2197 palavras

A bagunça dos plugins proprietários: o jardim murado que ninguém planejou

Empresas de médio porte operam, em média, 4 a 7 agentes de observabilidade em produção — Datadog APM, New Relic, exporter de logs proprietário, OpenTelemetry Collector legado em uma ou duas linguagens, Dynatrace OneAgent, e SDKs customizados para tracing escritos entre 2019 e 2022. Cada agent tem dashboard, alerta, plantão, contrato, custo por host e vocabulário próprio. A bagunça não aparece no roadmap. Aparece na fatura mensal.

O caso típico em engenharia brasileira de médio porte entre 2023 e 2026 mostra o padrão. A base tem Java, Node e Python. Java usa agent Datadog, Node usa agent New Relic, Python usa OTel em janela experimental e agent Datadog em produção. Os traces não compartilham trace ID entre as três linguagens. Quando um request atravessa as três, o engenheiro abre três dashboards em três UIs para reconstruir o caminho. O custo é dezenas de minutos por incidente.

A segunda fonte de bagunça é o versionamento. Quando o agent Datadog muda de versão, três coisas quebram: dashboard de métricas customizadas, alerta com tags depreciadas, e código que assumia trace ID em formato específico. São 1 a 3 sprints por upgrade — e o upgrade é trimestral. O time gasta 8% a 15% do tempo de engenharia mantendo integração.

A terceira fonte é a correlação cross-service. Em microsserviços, um request atravessa 5 a 15 serviços. Quando os serviços usam agents diferentes, o trace distribuído quebra em cada fronteira. O trace ID muda, o timestamp pode ser em milissegundos em um agent e microssegundos em outro. Correlação cross-service deixa de existir de fato. O time sabe que o request passou pelo serviço X porque X escreveu log, mas não sabe quanto tempo X gastou.

Esse é o custo invisível. Não está no orçamento. Está no MTTR, no plantão, no backlog de incidents que viram post-mortems.

O que OpenTelemetry realmente entrega: três signals, um SDK por linguagem

OpenTelemetry é projeto da CNCF, incubado em 2019 e graduado em 2021, que padroniza traces, métricas e logs em especificação única. OpenTelemetry tem API e SDK por linguagem — Java, Python, Node, Go, .NET, Ruby, PHP, Rust, Erlang, Swift. O protocolo é OTLP, aberto, com protobuf ou JSON sobre HTTP ou gRPC. O OpenTelemetry Collector, escrito em Go, recebe OTLP, processa, roteia e exporta para qualquer backend.

O ponto operacional é simples: instrumentar uma vez, exportar para qualquer backend.

O padrão aberto de observabilidade resolve três problemas de uma vez. Primeiro, elimina divergência de trace ID entre linguagens — todos os SDKs OTel injetam o mesmo formato de contexto, e o Collector propaga esse contexto sem perda. Segundo, elimina o versionamento quebrando — quando o Collector atualiza, a instrumentação continua válida porque OTLP é estável. O código é resiliente a mudanças de backend. Terceiro, elimina lock-in por exportação — se o contrato com Datadog vence em 2027, basta apontar o Collector para Grafana Tempo.

Três signals cobertos por um único SDK. É API pensada para os três sinais como cidadãos de primeira classe. Métricas têm os mesmos primitivos semânticos que traces — mesmos attributes, mesma convenção de nomenclatura, mesmo modelo de resource. Logs seguem o mesmo modelo. Um evento correlacionado entre os três sinais funciona sem código de cola.

A CNCF Annual Survey 2024 colocou OpenTelemetry como segundo projeto mais usado em produção após Kubernetes. Datadog em agosto de 2023 e New Relic em 2024 declararam OpenTelemetry como caminho de ingestão prioritário. Honeycomb publicou em 2024 que OpenTelemetry é o fim do APM tradicional. O movimento de mercado não é mais controverso. É o default.

A especificação técnica é estável. Traces GA desde 2021. Métricas GA desde 2023. Logs GA desde 2024. Profiles em beta em 2025, com GA previsto para 2026. O ponto é que 80% do que uma empresa precisa está em GA, com API estável.

Por que “vendor lock-in de observabilidade” é o custo invisível

O lock-in de observabilidade é mais profundo que o lock-in de banco de dados ou de cloud. Não aparece na comparação de custo por hora. Aparece no custo de saída.

Sair de Datadog exige reescrever cada SDK proprietário em cada linguagem para usar OpenTelemetry. Sair de New Relic exige migrar cada dashboard NRQL para query equivalente em Grafana. Sair de Dynatrace exige reprocessar cada dashboard PurePath. Cada migração é projeto de meses. Durante a migração, a empresa paga dois backends simultaneamente. O custo de saída é, na prática, 12 a 24 meses de billing duplicado mais 6 a 12 meses de engenharia.

Esse é o cálculo que torna o lock-in eficaz. Não é o custo mensal do contrato. É o custo projetado de saída que impede o time de avaliar troca.

A segunda camada é a correlação proprietária. Cada vendor construiu modelo próprio de correlação entre trace, log e métrica. Datadog correlaciona por dd.trace_id. New Relic por traceId. Dynatrace por dt.trace_id. Se o time construiu runbooks que dependem dessa correlação, a saída exige reescrever os runbooks. O custo é operacional, não financeiro. Aparece em MTTR aumentado durante a transição.

A terceira camada é o dashboard como ativo. Cada dashboard é página que o time aprendeu a ler. A posição dos gráficos, a granularidade, o agrupamento por tag — tudo é específico do backend. Trocar de backend é trocar a interface de operação. Em time de 20 pessoas, são 20 pessoas reaprendendo durante 4 a 8 semanas. É centenas de milhares de reais de custo não orçado.

O padrão aberto de observabilidade quebra as três camadas. Correlação é OTLP — mesmo trace ID em qualquer backend. Dashboard é exportável como JSON e reimportável em Grafana ou Honeycomb com perda mínima. Runbook é escrito em cima de queries OTLP. O custo de saída cai de 24 meses para 3 a 6 meses. O risco de renovação forçada cai junto.

A leitura operacional é direta: enquanto a empresa opera 100% com agents proprietários, ela paga imposto mensal invisível sobre toda feature nova que precisa ser observada. Cada novo serviço precisa de três integrações em vez de uma. O tempo de onboarding de novos engenheiros é multiplicado pelo número de vendors.

OTel Collector: a peça que transforma SDK em plataforma

O OpenTelemetry Collector é processo Go standalone, distribuído como binário ou imagem Docker, que recebe OTLP, processa e exporta para qualquer backend. O coletor opera como agent em cada host, gateway centralizado, ou modelo híbrido.

A escolha de deployment é técnica. Agent em cada host é melhor para escala alta, permite tail-based sampling local. Gateway centralizado é melhor para ambientes menores e configuração uniforme. Híbrido usa receivers em cada host para dados de alta cardinalidade e gateway para agregação.

A configuração é declarativa, em YAML, com receivers, processors, exporters e pipelines. O arquivo é versionado em git. A mudança é revisável em PR. A auditoria de “o que está sendo exportado para onde” responde em 30 segundos lendo o YAML — não em três UIs proprietárias.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
processors:
  batch:
    timeout: 5s
  memory_limiter:
    limit_percentage: 80
exporters:
  otlp/datadog:
    endpoint: https://api.datadoghq.com:443
  otlp/grafana:
    endpoint: tempo-gateway:4317
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/datadog, otlp/grafana]

Esse exemplo mostra o ponto: o mesmo trace pode ser exportado para Datadog e Grafana Tempo simultaneamente. O time decide em tempo de configuração quais traces vão para onde. A mudança é no YAML. Sem reescrever SDK. Sem re-deploy de serviço.

O segundo papel do Collector é sampling. Tail-based sampling — decidir se um trace vale ser armazenado depois de ver o trace completo — só funciona em Collector centralizado. Agent legado proprietário raramente oferece tail-based sampling — porque o vendor quer cobrar por 100% dos traces.

O terceiro papel é enrichment. O Collector adiciona attributes automaticamente — environment, region, version, k8s_pod_name — sem que o código precise instrumentar cada um. O código marca o evento; o Collector adiciona o contexto operacional.

Onde OTel ainda não substitui — e onde não vai substituir tão cedo

Três áreas onde OpenTelemetry ainda não substitui o agent proprietário em 2026.

A primeira é APM com profiling de produção contínuo. OTel tem signal de profiles em beta, mas a integração com Datadog Continuous Profiler ou New Relic CodeStream ainda é limitada. Profiling em produção requer amostragem estatística em tempo de execução, com correlação fina entre linha de código e trace ID. OTel cobre o caso em beta, mas a estabilidade ainda é inferior aos profilers proprietários maduros. Para times que precisam de profiling contínuo como feature central, manter o agent proprietário por 12 a 18 meses é razoável.

A segunda é auto-instrumentation zero-code para linguagens com reflection limitada. O agent Datadog em Java instrumenta 50+ bibliotecas automaticamente via bytecode manipulation. O SDK OpenTelemetry faz o mesmo via Java Agent, mas a cobertura é menor — cerca de 30+ bibliotecas estáveis. Para empresas que dependem de auto-instrumentation profunda em bibliotecas internas customizadas, o gap ainda é real. A solução é gradual: OTel nas bibliotecas com auto-instrumentation, agent proprietário nas que não têm, migrar quando a cobertura OTel estabilizar.

A terceira é observabilidade de front-end com Real User Monitoring avançado. OTel tem SDK web e mobile, mas Datadog Browser RUM e New Relic Browser oferecem session replay, heatmap, error tracking visual e correlação com backend trace que OTel ainda não cobre em paridade. Para empresas onde o front-end é o produto (e-commerce, SaaS B2C), manter Browser RUM proprietário por 12 a 24 meses é defensável.

A leitura operacional é: OpenTelemetry não é substituição total em 2026. É substituição gradual, signal por signal, com coexistência mensurável entre OpenTelemetry e agent proprietário durante a transição. O critério de saída por signal é OpenTelemetry GA, cobertura de auto-instrumentation suficiente, exporter estável para o backend escolhido. Não migrar tudo de uma vez. Migrar onde o sinal é commodity. Manter onde OpenTelemetry ainda está em beta.

O ROI da migração: como vender o projeto para o time e para o CFO

A migração para OpenTelemetry é projeto de engenharia com ROI composto. Não é troca de fornecedor — é eliminação de dívida operacional recorrente. O ROI se mede em três vetores.

O primeiro vetor é mensurável. Se o time gasta 12% do tempo mantendo integração com agent proprietário, migrar para OTel reduz para 3% a 5%. Em time de 15 pessoas com custo médio de R$ 18.000/mês, é R$ 32.000 a R$ 60.000 por mês de horas recuperadas. O payback típico é de 6 a 12 meses.

O segundo vetor é projetado. Se a empresa avalia troca de backend em 2027 ou 2028, o custo de saída cai de R$ 2M a R$ 5M para R$ 500k a R$ 1.5M. É economia contingente que muda a margem de negociação com o vendor. O CFO entende esse número.

O terceiro vetor é o mais difícil de mensurar: velocidade de onboarding. Com OTel, instrumentar um novo serviço é adicionar dependência e configurar Collector. Com agent proprietário, é adicionar agent, configurar licença, validar dashboard. Em empresa que lança 30 a 50 serviços por ano, são 60 a 250 dias-homem recuperados.

O plano de migração tem três fases. Fase 1 (1 a 3 meses): instrumentar serviços novos com OTel, mantendo agents legados em paralelo. Fase 2 (3 a 9 meses): migrar Java e Python, substituir agent proprietário por auto-instrumentation OTel. Fase 3 (9 a 18 meses): migrar Node e Go. Coexistência, não big-bang.

O padrão aberto de observabilidade não é fim de fornecedor. É fim de lock-in operacional. O fornecedor pode ser Datadog, New Relic, Grafana, Dynatrace, Honeycomb ou um mix. O que muda é que a escolha de fornecedor volta a ser decisão técnica, não decisão irreversível. Esse é o ROI real.

Critério de saída por signal. A migração não é big-bang, é decisão por signal com três condições operacionais: signal em GA na especificação (traces, métricas e logs estão GA desde 2021, 2023 e 2024; profiles em beta até 2026), cobertura de auto-instrumentation suficiente para as linguagens em produção (Java e Python maduros, Node e Go estáveis), e exporter estável para o backend atual ou de destino. Quando as três passam, a migração daquele signal está autorizada. Manter agent legado onde as três não passam. Remover agent legado só quando o último signal migrado atinge as três.

A métrica de acompanhamento é simples: percentual de traces gerados por SDK OTel no Collector. Meta de 80% em 9 meses. Cada ponto percentual representa horas de manutenção recuperadas mais custo de saída projetado que deixa de ser bloqueador de negociação com vendor. A métrica é pública dentro do time e revisada mensalmente em reunião de plataforma junto com a fatura do backend atual.

Leitura relacionada

• Feature flag: deploy seguro de mudança irreversível — mostra o critério operacional para reverter deploy quando a migração de observabilidade introduzir regressão, mesmo padrão de rollout controlado aplicável.
• Platform engineering: quando DevOps virou complexo demais — explica por que stack fragmentada de agents proprietários é sintoma de platform debt, não de escolha técnica.
• O custo do onboarding com Clean Code dogmático — o mesmo padrão de custo invisível aparece em dogmas de código e em dogmas de vendor, ambos cobram juros do próximo dev.