Se você tem mais de 50 serviços em produção, provavelmente já sentiu a dor:
- Datadog sobe de custo a cada contratação de developer
- New Relic muda de pricing e sua conta dobra num trimestre
- Time quer migrar para Grafana Cloud mas “tudo está instrumentado com o SDK do Datadog”
- Cada vendor manda usar o agent deles, com sintaxe própria, com escopo diferente
A conversa sobre observabilidade tem duas partes: coletar (onde os dados vêm) e consumir (onde você olha). O problema é que vendors te vendem os dois juntos, acoplados, e depois você não consegue separar.
OpenTelemetry resolve a primeira parte. Com rigor.
1. O que OpenTelemetry é (e não é)
É: um padrão aberto, mantido pela CNCF, para instrumentar aplicações (traces, metrics, logs) de forma vendor-neutral.
Ou seja: você instrumenta uma vez usando SDK e APIs do OTel. Os dados saem em um formato padrão (OTLP). Você pluga em qualquer vendor (Datadog, New Relic, Honeycomb, Grafana, Jaeger, AWS X-Ray, Azure Monitor, GCP Cloud Trace) sem tocar o código.
Não é: um backend de observabilidade. OTel não armazena dados, não renderiza dashboards, não alerta. Para isso você ainda precisa de uma ferramenta.
Pense assim: OTel está para observabilidade como USB está para periféricos. Conecta tudo em tudo.
2. Por que isso importa agora
Três coisas mudaram nos últimos 18 meses:
- Auto-instrumentation madura. Em Java, Python, Node, Go e .NET você roda um agent e 80% das libs comuns (HTTP clients, DBs, message queues, frameworks web) ficam instrumentadas sem mudança de código.
- OTLP virou default. Datadog, New Relic, Grafana, Elastic aceitam OTLP direto. Não precisa mais converter.
- Custo de observabilidade explodiu. APMs tradicionais cobram por host + por custom metric + por retention. Em contas acima de R$ 2M/ano, lock-in vira risco real de negócio.
Se você está começando observabilidade hoje ou está na hora de renovar contrato, começar por OTel é a decisão default.
3. A arquitetura mínima
┌─────────────┐ OTLP ┌──────────────┐
│ App (SDK) │─────────────▶│ Collector │
└─────────────┘ └──────┬───────┘
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
┌─────────┐ ┌──────────┐ ┌──────────┐
│ Datadog │ │ Grafana │ │ S3 / GCS │
│ (prod) │ │(staging) │ │ (raw) │
└─────────┘ └──────────┘ └──────────┘
Peças:
- SDK — instrumenta a aplicação. Pode ser auto (agent) ou manual (API calls no código).
- Collector — recebe OTLP, aplica filtros/sampling/redact e encaminha para um ou mais destinos.
- Backend(s) — qualquer vendor compatível.
A mágica está no Collector: você pode mandar os mesmos dados para 2 destinos diferentes (produção + analytics de longo prazo em S3, por exemplo) sem custo de instrumentar duas vezes.
4. Adoção em 4 fases
Guia realista baseado em 6 clientes que adotamos OTel nos últimos 12 meses.
Fase 1 — Piloto em 1 serviço (2 semanas)
Escolha:
- 1 serviço de backend importante (não o mais crítico)
- 1 linguagem que sua equipe domina
- 1 vendor já contratado (Datadog ou Grafana Cloud)
Instrumentar via auto-instrumentation agent. Zero mudança de código na primeira semana.
Objetivo: validar que os traces chegam ao vendor, que latências batem com o que você já vê, e que a carga no serviço é tolerável (tipicamente 1-3% de overhead).
Fase 2 — Roll-out por linguagem (1-2 meses)
Padronize via:
- Template de Dockerfile com o agent
- Variáveis de ambiente padrão (OTEL_SERVICE_NAME, OTEL_RESOURCE_ATTRIBUTES, OTEL_EXPORTER_OTLP_ENDPOINT)
- Sampling policy declarada em config, não em código
Faça uma linguagem por vez. Não tente adotar em 4 stacks simultâneas — você vai quebrar em aprendizados perdidos.
Fase 3 — Deploy do Collector como componente central (1 mês)
Até agora os apps mandam OTLP direto para o vendor. Agora suba um Collector (deployment Kubernetes com 3 replicas, ou ECS service).
Ganhos imediatos:
- Redact de PII no pipeline (CPF, email, tokens) antes de sair da sua rede
- Sampling inteligente (100% de erros, 10% de sucessos) — reduz custo em 50-80%
- Failover: se o vendor cair, collector buffera localmente
- Fan-out: mesmo trace vai para vendor A (prod hot) e vendor B (analytics cold)
Fase 4 — Logs e metrics correlacionados (2-3 meses)
Agora expanda OTel para logs (via logback/slf4j/python logging appenders) e metrics (MeterProvider).
O grande ganho aqui é correlação: trace_id em todos os logs, exemplars em histogramas de métricas apontando para traces concretos. Quando um alerta dispara, você salta de gráfico → trace → log em um clique.
5. Armadilhas comuns
Armadilha 1 — Instrumentar manualmente demais
Começo o post dizendo “auto-instrumentation cobre 80%”. Esse 80% é suficiente para os primeiros 6 meses. Não deixe o time perder semanas criando spans manuais para tudo.
Regra: só instrumente manualmente o que tem valor de negócio (operações de domínio, decisões de autorização, efeitos colaterais caros). Resto, auto cobre.
Armadilha 2 — Sampling errado
Sampling é a ferramenta mais poderosa e a mais fácil de usar mal.
- Head-based sampling (decidir na entrada): simples, mas pode perder erros raros
- Tail-based sampling (decidir no Collector depois que o trace terminou): pega 100% dos erros + % dos sucessos, é o que você provavelmente quer
Regra: error + slow first, depois amostra o resto.
Armadilha 3 — Vendor “suporta OTLP” mas com asterisco
Nem todo vendor suporta OTLP igualmente. Leia a letra miúda:
- Alguns não aceitam logs via OTLP ainda (só metrics + traces)
- Alguns exigem tags específicas para certos dashboards
- Alguns limitam custom attributes em spans
Antes de apostar em vendor X, rode um POC de 1 semana com seu dado real.
Armadilha 4 — Cardinality explosion
OpenTelemetry não protege você de criar métricas com labels de alta cardinalidade (user_id, trace_id, request_id em métricas). Isso mata backends.
Regra: em métricas, labels devem ser enumeráveis em menos de 10.000 valores distintos. Para o resto, use atributos de span (em traces) ou logs estruturados.
6. Comparação prática: OTel-first vs. vendor-SDK
| Aspecto | Vendor SDK (Datadog, etc.) | OTel + Vendor |
|---|---|---|
| Setup inicial | 1 hora | 3-5 horas |
| Cobertura auto | Excelente | Boa (melhorando rápido) |
| Vendor lock-in | Alto | Mínimo |
| Custo de troca de vendor | Alto (refactor) | Baixo (muda config) |
| Custo de multi-destino | Alto | Baixo |
| Compliance / redact local | Depende do vendor | Nativo no Collector |
| Comunidade / ecossistema | Fechado | Aberto, CNCF |
OTel é mais lento no setup inicial, mas paga o investimento em 3-6 meses quando o primeiro contrato de vendor precisa ser renegociado.
7. Stack recomendado por porte
- Startup / mid-market (< 20 serviços): Auto-instrumentation + Grafana Cloud Free/Pro. Custo baixo, onboarding rápido. Adicionar Collector quando ultrapassar 50 GB/mês de ingestão.
- Enterprise (20-200 serviços): Collector deploy + vendor principal (Datadog/New Relic/Grafana Cloud Enterprise) + cold storage em S3/GCS para retention longa barata.
- Enterprise regulado (bancos, saúde): Collector com redact nativo + vendor homologado + exportação duplicada para SIEM (Splunk/Elastic).
8. Pergunta que você deveria estar se fazendo agora
“Se meu contrato de Datadog/New Relic dobrar de preço na renovação, quanto tempo e esforço levo para migrar?”
Se a resposta for “6-12 meses de trabalho”, você tem lock-in. Começar a adotar OTel nos próximos 90 dias cortaria esse número para ~1 mês.
Observabilidade é infraestrutura de decisão. Lock-in em infraestrutura de decisão é risco estratégico.
Na Redgator: rodamos 7 projetos de observabilidade baseados em OpenTelemetry nos últimos 18 meses, do e-commerce ao setor bancário. Se quiser um diagnóstico da sua stack atual e um plano de transição, fale com um especialista.
Publicado em 28/02/2026. Última revisão: 28/02/2026.