Como reduzir a sua fatura do Datadog com OpenTelemetry

A fatura que cresce sozinha#

Todo trimestre, a mesma cena se repete em algum canal do Slack: alguém compartilha a última fatura do Datadog e a thread se enche de incredulidade, humor ácido e o clássico "eu avisei". Se a sua fatura cresceu muito mais do que a sua infraestrutura desde que você começou, você não é um caso raro.

O padrão costuma ser idêntico. Você começa com APM para um punhado de serviços. Depois adiciona logs, porque correlacionar traces com linhas de log é útil. Em seguida, as métricas custom vão entrando. Alguém ativa o RUM. E um dia você abre a fatura e descobre que observar a sua infraestrutura custa uma fração incômoda do que custa a própria infraestrutura.

Isto não é um ataque ao Datadog. O produto é realmente bom e a interface continua entre as melhores do mercado. O problema é estrutural: o modelo de preços cobra por dimensão (por host, por GB, por span, por série de métrica, por sessão), e isso cria um imposto sobre o crescimento que pesa muito para times de porte médio. Este guia explica de onde vem o gasto e como usar o OpenTelemetry para recuperar o controle sem perder visibilidade.

Documentação: Datadog · Pricing ↗

Por que ela dispara: o preço se multiplica, não se soma#

O Datadog não cobra uma mensalidade simples. Ele fatura separadamente cada produto e cada dimensão, e essas dimensões crescem juntas quando você cresce:

• Infraestrutura: por host monitorado.
• APM: por host com traces, mais o volume de spans ingeridos e indexados acima do que está incluído no plano.
• Logs: cobra-se a ingestão por GB e, à parte, a indexação por eventos conforme o período de retenção. Um mesmo log pode ser pago duas vezes.
• Métricas custom: cada combinação única de nome de métrica e valores de tags conta como uma métrica faturável. Um histograma ou uma distribuição geram, por padrão, várias séries por combinação. Por isso, instrumentar com Prometheus ou OpenTelemetry sem controlar os rótulos pode gerar milhares de séries por serviço.
• RUM e outros produtos: por sessões ou por volume, conforme o produto.

O resultado é uma fatura que cresce de forma superlinear: adicionar um serviço não adiciona só um host, adiciona spans, logs e, principalmente, novas combinações de tags. Na maioria dos times, APM e logs são as linhas mais pesadas, e essa observação define a estratégia: comece por onde o gasto se concentra na sua própria fatura. Os preços mudam com frequência, então consulte sempre a página oficial de preços e o detalhamento de uso da sua conta.

Para se aprofundar: Por que o custo cloud preocupa mais que a segurança nas PMEs

Documentação: Datadog · Pricing ↗ · Datadog · Faturamento de métricas custom ↗ · Datadog · Faturamento de APM ↗ · Datadog · Índices de logs e filtros de exclusão ↗

A IA infla a telemetria#

Há uma variável nova estourando orçamentos: os workloads de IA. Uma única requisição de inferência pode produzir traces de várias etapas (recuperação de contexto, chamadas ao modelo, ferramentas, retries), atributos de alta cardinalidade como identificadores de modelo ou de prompt, contagens de tokens que vale rastrear por custo e novas métricas de avaliação.

Cada uma dessas coisas é mais uma dimensão que a sua plataforma de observabilidade pode cobrar: mais spans por requisição, mais séries a cada tag nova, mais GB de logs com prompts e respostas. Se você adicionar monitoramento de LLMs sem decidir antes quais atributos realmente precisa e com qual amostragem, a fatura vai refletir isso rápido.

A regra aqui é a mesma do resto do guia: se a sua observabilidade custa mais do que o valor das decisões que ela permite tomar, algo quebrou. Defina quais perguntas você quer responder sobre seus workloads de IA e colete apenas a telemetria que as responde.

Documentação: Datadog · Faturamento de métricas custom ↗ · OpenTelemetry · Amostragem ↗

A saída não é jogar o Datadog fora: é um modelo híbrido#

Este é o detalhe que a maioria das threads do Slack ignora: o objetivo não é migrar tudo de uma vez para outra ferramenta. O objetivo é deixar de ser refém de um modelo de preços que pune você por crescer.

A jogada que funciona é um modelo híbrido. Você mantém o Datadog para o que realmente aproveita (normalmente a experiência de APM, dashboards e alertas em fluxos críticos) e move o volume de baixo valor para backends mais baratos, como Grafana Loki para logs, Grafana Tempo ou Jaeger para traces, e Grafana Mimir ou VictoriaMetrics para métricas.

A peça que torna isso possível é o OpenTelemetry. Ele é um padrão aberto e independente de fornecedor para gerar, coletar e exportar traces, métricas e logs. Você instrumenta uma única vez com os SDKs e o protocolo OTLP, e o OpenTelemetry Collector decide depois para onde vai cada sinal. Trocar de destino é mudar a configuração do collector, não o código da aplicação.

Os logs costumam ser a primeira coisa a mudar, por dois motivos: costumam estar entre as linhas mais caras da fatura e, emitidos via OpenTelemetry, são os mais fáceis de redirecionar. O Loki aceita OTLP nativamente, então basta apontar um exporter para o endpoint dele. Mantenha o trace_id como campo do log para poder correlacioná-lo com os traces.

Documentação: OpenTelemetry · O que é OpenTelemetry ↗ · OpenTelemetry · Configuração do Collector ↗ · Grafana Loki · Ingestão de logs com OpenTelemetry ↗

Um collector que decide para onde vai cada sinal#

O exemplo a seguir mostra um OpenTelemetry Collector (distribuição contrib) que envia todos os traces para o Tempo, apenas uma amostra dos de produção para o Datadog, as métricas de aplicação para o Mimir e os logs, sem DEBUG, para o Loki.

receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }

processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 80
    spike_limit_percentage: 20
  batch: {}
  # Não pague no Datadog pelos spans de staging (eles continuam indo para o Tempo)
  filter/no-staging:
    error_mode: ignore
    trace_conditions:
      - resource.attributes["deployment.environment.name"] == "staging"
  # Envia ao Datadog apenas uma amostra dos spans de produção
  probabilistic_sampler:
    sampling_percentage: 20
  # Descarta logs DEBUG antes de enviá-los a qualquer destino
  filter/no-debug:
    error_mode: ignore
    log_conditions:
      - log.severity_number < SEVERITY_NUMBER_INFO

connectors:
  # Calcula as métricas de APM (hits, erros, latência) com 100 % dos traces
  datadog/connector: {}

exporters:
  datadog:
    api:
      site: datadoghq.com
      key: ${env:DD_API_KEY}
  otlp/tempo:
    endpoint: tempo:4317
    tls: { insecure: true }
  otlphttp/loki:
    endpoint: http://loki:3100/otlp
  otlphttp/mimir:
    endpoint: http://mimir:8080/otlp

service:
  pipelines:
    traces/all:              # todos os traces, sem amostragem, para o Tempo
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/tempo]
    traces/datadog-in:       # produção para o connector (sem amostragem)
      receivers: [otlp]
      processors: [memory_limiter, filter/no-staging]
      exporters: [datadog/connector]
    traces/datadog-out:      # amostra para o Datadog
      receivers: [datadog/connector]
      processors: [probabilistic_sampler]
      exporters: [datadog]
    metrics/apm-stats:
      receivers: [datadog/connector]
      exporters: [datadog]
    metrics:                 # métricas de aplicação para o Mimir
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlphttp/mimir]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, filter/no-debug, batch]
      exporters: [otlphttp/loki]

Três detalhes fazem a diferença entre economizar e quebrar a observabilidade:

• Calcule as métricas de APM antes de amostrar. Se você amostra os traces antes que o Datadog os veja, as taxas de requisições, erros e latências de APM são calculadas sobre uma fração do tráfego. O Datadog Connector resolve isso: recebe 100 % dos traces, calcula essas estatísticas e depois reenvia a amostra.
• Filtre por atributos de recurso padrão. A convenção semântica atual é deployment.environment.name; se os seus serviços ainda emitem deployment.environment, ajuste a condição.
• Proteja o próprio collector. O memory_limiter deve vir primeiro em cada pipeline para que um pico de telemetria não derrube o collector.

A amostragem probabilística é simples, mas não distingue traces interessantes. Se você precisa manter sempre os traces com erro ou os mais lentos, use tail sampling, que decide quando o trace está completo; em troca, exige que todos os spans de um trace cheguem à mesma instância do collector.

Para se aprofundar: SLIs e SLOs mal definidos: por que geram alertas falsos

Documentação: OpenTelemetry · Configuração do Collector ↗ · Datadog · OpenTelemetry Collector e Datadog Exporter ↗ · OpenTelemetry Collector Contrib · Datadog Connector ↗ · OpenTelemetry Collector Contrib · Filter processor ↗ · OpenTelemetry Collector Contrib · Tail sampling processor ↗ · OpenTelemetry · Amostragem ↗ · Grafana Tempo · Documentação ↗ · Grafana Mimir · Configurar o OpenTelemetry Collector ↗

Plano de ação: o que mover e em que ordem#

Não migre por entusiasmo; migre por retorno. Ataque primeiro o que tem custo alto e esforço baixo, e deixe para o final o que exige mais trabalho ou onde a ferramenta cara realmente brilha.

• Mapeie suas dimensões faturáveis. Abra o detalhamento de uso da sua conta do Datadog e classifique cada linha: hosts, spans ingeridos e indexados, GB de logs ingeridos, eventos indexados, métricas custom, sessões de RUM. Identifique quais crescem mais rápido do que a sua infraestrutura.
• Use primeiro as alavancas que não exigem migração. Filtros de exclusão nos índices de logs, controles de ingestão de APM e Metrics without Limits para decidir quais tags são indexadas podem cortar gastos sem mover nada de lugar.
• Desvie os logs de baixa prioridade. Logs de debug, health checks e ruído de desenvolvimento não precisam ser indexados no Datadog. Envie-os para o Loki mantendo o trace_id para a correlação.
• Controle a cardinalidade das métricas. Cada rótulo de alta cardinalidade (IDs de usuário, de requisição, URLs completas) multiplica as séries. Remova-o no collector ou redirecione essas métricas para o Mimir ou o VictoriaMetrics.
• Faça amostragem de traces. Você não precisa de 100 % dos spans para entender a saúde de um serviço, desde que as métricas de APM sejam calculadas antes da amostragem.
• Mantenha os traces críticos no Datadog até validar a alternativa. Deixe os fluxos de pagamento e os serviços core no Datadog enquanto confirma que o Tempo ou o Jaeger cobrem o resto com a experiência de que o seu time precisa.

Começar por logs e cardinalidade costuma recuperar a maior parte da economia com o menor risco, e muitas vezes ninguém percebe a diferença nos dashboards.

Documentação: Datadog · Detalhamento de uso (Plan and Usage) ↗ · Datadog · Índices de logs e filtros de exclusão ↗ · Datadog · Controles de ingestão de APM ↗ · Datadog · Metrics without Limits ↗ · VictoriaMetrics · Integração com OpenTelemetry ↗

Tudo no Datadog vs. stack híbrido com OpenTelemetry#

O stack aberto não é de graça: ele move o gasto de licenças para infraestrutura e horas de engenharia. A decisão certa depende de quanto você paga hoje por volume de baixo valor e de se o seu time consegue operar esses componentes, ou pagar pela versão gerenciada deles.

Documentação: Datadog · Faturamento de métricas custom ↗ · Grafana Loki · Ingestão de logs com OpenTelemetry ↗ · Grafana Tempo · Documentação ↗ · Grafana Mimir · Configurar o OpenTelemetry Collector ↗

Quando vale ficar no Datadog#

Sejamos justos: há casos em que uma fatura alta se justifica. Se você é uma organização grande, com requisitos de compliance complexos e dezenas de integrações que um time pequeno não quer operar, pagar por uma plataforma polida e unificada faz todo o sentido. Operar o seu próprio stack de observabilidade é trabalho de engenharia real e contínuo.

Onde a conta muda é no mid-market: um time de porte médio com algumas dezenas de microsserviços no Kubernetes raramente precisa pagar o preço cheio por cada log de debug, cada span de staging e cada combinação de tags. Nesse caso, o ecossistema aberto em torno do OpenTelemetry está maduro para produção, e a pergunta deixa de ser "eu consigo?" e passa a ser "o que eu movo primeiro?".

Documentação: OpenTelemetry · O que é OpenTelemetry ↗

O resumo em uma linha#

Instrumente com OpenTelemetry para não ficar preso a nenhum fornecedor. Use primeiro as alavancas do Datadog que não exigem migração, mova os logs de baixo valor, controle cardinalidade e amostragem no collector, e mantenha no Datadog apenas o que você realmente não consegue replicar. O objetivo não é economizar por economizar: é recuperar o controle de uma fatura que hoje cresce sozinha.