Datadog: o que é, como funciona e quanto custa a plataforma de observabilidade

O Datadog é uma plataforma SaaS de monitoramento e observabilidade que chega pronta para uso. Não há servidor para provisionar, banco de séries temporais para dimensionar nem cluster para escalar quando o volume de dados cresce.

Essa conveniência tem um preço. Ele é o ponto que mais surpreende quem contrata. O licenciamento é modular: cada capacidade tem a própria unidade de cobrança. A conta final é a soma de dezenas dessas linhas.

Este guia percorre o que a plataforma faz, módulo por módulo, como cada um é cobrado e em que cenários ela compensa. O objetivo é que você termine sabendo se o Datadog serve para o seu caso, não só o que ele promete.

O que é o Datadog

O Datadog é uma plataforma SaaS de observabilidade que reúne métricas de infraestrutura, logs, traces de aplicação, experiência do usuário e segurança em uma interface única, com correlação automática entre esses sinais. Você instala um agente, conecta as integrações de nuvem e passa a diagnosticar incidentes sem alternar entre ferramentas.

Lançada em 2010 como serviço de monitoramento de infraestrutura em nuvem, a plataforma cresceu até cobrir a cadeia inteira: servidores, containers, aplicações, rede, bancos de dados e a experiência de quem usa o sistema na ponta.

O modelo é inteiramente SaaS. Você instala um agente nos hosts, conecta as integrações de nuvem e os dados passam a fluir para a plataforma. Não existe versão on-premises: o dado sai do seu ambiente e é processado na infraestrutura do fornecedor.

Esse desenho explica tanto a força quanto o limite do produto. A força é o tempo até o primeiro valor, que se mede em horas. O limite é a soberania do dado e o custo, que crescem junto com o volume que você envia.

O tour abaixo percorre a plataforma inteira, módulo por módulo, com a interface em uso. São 45 minutos divididos em capítulos, então dá para pular direto para o bloco que interessa: infraestrutura, APM, segurança ou custos.

Plataforma modular: como o Datadog é cobrado

Este é o assunto que deveria vir primeiro em qualquer avaliação e quase nunca vem. O Datadog não tem preço único: tem uma unidade de cobrança por módulo. As unidades não se parecem entre si.

A infraestrutura é cobrada por host monitorado, por mês. Os logs são cobrados em duas etapas separadas, a ingestão por volume e a retenção por período. O APM é cobrado por host de aplicação, com limite de spans incluído e cobrança adicional acima dele.

Os testes sintéticos são cobrados por execução. O monitoramento de usuário real é cobrado por sessão. A segurança em nuvem é cobrada por host. Os usuários que só olham painéis costumam ter licença própria.

Os números ajudam a dimensionar. Na tabela oficial vigente, a infraestrutura sai por US$ 15 por host/mês no plano Pro anual e US$ 23 no Enterprise, o APM adiciona US$ 31 por host/mês, e os logs cobram US$ 0,10 por GB ingerido mais US$ 1,70 por milhão de eventos indexados.

Repare no efeito de empilhamento: um host com aplicação instrumentada já custa a soma de duas linhas antes de qualquer log entrar na conta. Uma operação de porte médio aciona oito ou dez medidores diferentes sem perceber, cada um com a própria elasticidade.

O que acontece quando você passa do contratado

Cada plano embute uma franquia e cobra o excedente à parte. O plano de infraestrutura inclui um número fixo de métricas customizadas e de containers por host; acima disso, container passa a ser cobrado por hora e métrica customizada por unidade.

No APM a lógica se repete com spans: há um volume de ingestão e de indexação incluído, e o que passa disso vira cobrança por milhão de eventos. Não há corte de serviço quando o limite estoura, o que é conveniente na operação e perigoso no orçamento: a conta cresce em silêncio até o fechamento do mês.

Onde a conta costuma estourar

O vilão mais comum não é o número de hosts, que é previsível. São as métricas customizadas. Cada combinação distinta de tags gera uma série temporal cobrada à parte. O total cresce por multiplicação, não por soma.

Uma métrica com cinco tags de dez valores cada gera dezenas de milhares de séries. O time acha que criou uma métrica; a fatura registra um universo delas. É o efeito que tratamos em cardinalidade de métricas.

O segundo vilão são os logs de debug esquecidos em produção. Como a ingestão é cobrada por volume, um serviço verboso após um deploy consegue dobrar a linha de logs do mês sem que ninguém tenha mudado o contrato.

Infraestrutura, containers e Kubernetes

O módulo de infraestrutura é a base sobre a qual o resto se apoia. O agente coleta métricas de CPU, memória, disco e rede de cada host e as apresenta em uma visão de mapa, onde cada quadrado é uma máquina e a cor indica o estado.

Para containers, a leitura muda de granularidade. A plataforma enxerga o container como unidade efêmera e agrega por serviço, deployment ou namespace, que é o recorte que faz sentido quando a instância vive minutos.

Em Kubernetes, a coleta cobre o plano de controle, os nós e as cargas de trabalho, com relação de pertencimento entre eles. Há também varredura de imagens em busca de vulnerabilidades conhecidas, ligando o inventário de containers ao catálogo de CVEs.

O inventário resultante é o que sustenta a correlação mais adiante. Sem saber que aquele pod pertence àquele serviço, que roda naquele nó, o resto da plataforma não conseguiria juntar os sinais sozinha.

Dashboards, monitores e gestão de incidentes

Cada integração ativada traz painéis prontos, com as métricas que importam para aquela tecnologia já dispostas. Isso resolve o problema de folha em branco que costuma travar a adoção de qualquer ferramenta de monitoramento nas primeiras semanas.

Os monitores são as regras de alerta. Podem observar uma métrica, uma consulta em logs, o resultado de um teste sintético ou a combinação de vários deles em uma condição composta.

Aqui aparece um detalhe de custo que passa despercebido: monitores que avaliam consultas complexas sobre grandes janelas de tempo consomem recursos cobrados. Um alerta mal desenhado sai caro sem nunca disparar.

Acima dos alertas existe uma camada de gestão de incidentes. A plataforma mantém escala de plantão, escalona quando ninguém reconhece o chamado, agrupa sinais relacionados em um incidente único e publica uma página de status para quem está fora da operação.

Há ainda execução de ações remotas a partir do alerta: reiniciar um serviço, girar uma chave, abrir um chamado. É a ponte entre detectar e responder, que costuma ser o trecho mais manual de qualquer operação.

APM, traces e Service Map

O módulo de APM instrumenta a aplicação e passa a registrar cada requisição como um trace, com o caminho completo entre serviços e o tempo gasto em cada etapa.

A leitura prática começa pela lista de serviços, ordenada por latência, taxa de erro e volume. Dali você abre o serviço lento, vê a distribuição dos tempos de resposta e desce até o trace individual que explica a cauda longa.

O Service Map é gerado a partir desses traces, sem desenho manual. A plataforma infere quem chama quem e monta o grafo de dependências, que se atualiza sozinho quando um serviço novo entra em produção.

Esse é o ponto em que a instrumentação vira arquitetura documentada. O mapa não é um diagrama que alguém desenhou e esqueceu de atualizar: é o retrato do que está de fato acontecendo em produção.

Logs, RUM e testes sintéticos

Os logs entram por uma pipeline que aceita processamento antes do armazenamento. Dá para descartar ruído, extrair campos e decidir o que vai para retenção longa e o que fica disponível apenas por poucos dias.

Esse controle importa mais do que parece. Como a cobrança separa ingestão de retenção, a pipeline bem configurada é o principal instrumento de contenção de custo do módulo.

O real user monitoring coleta a experiência do navegador ou do aplicativo do usuário final: tempo de carregamento, erros de JavaScript, travamentos e o caminho que a pessoa percorreu antes do problema.

Os testes sintéticos fazem o oposto. Em vez de esperar o usuário, robôs executam jornadas programadas em intervalos fixos, a partir de várias regiões. Eles avisam quando o fluxo de login ou de checkout quebra fora do horário de pico.

Rede, banco de dados e entrega de software

O módulo de rede mostra o tráfego entre serviços, containers e zonas de disponibilidade, com volume, retransmissões e latência de cada fluxo. É o que responde se a lentidão está na aplicação ou no caminho entre ela e a dependência.

Esse recorte resolve uma discussão recorrente entre times de aplicação e de infraestrutura. Em vez de cada lado defender a própria hipótese, o fluxo aparece medido, com origem e destino identificados pelo mesmo conjunto de tags do resto da plataforma.

O monitoramento de banco de dados desce ao nível da consulta. Ele lista as queries mais custosas, mostra o plano de execução e liga a consulta lenta ao serviço da aplicação que a disparou, fechando o caminho entre sintoma e origem.

A frente de entrega de software observa os pipelines de integração contínua: duração de cada etapa, testes instáveis e taxa de falha por branch. Ligando isso ao restante, dá para relacionar uma regressão de latência ao deploy exato que a introduziu.

Essa amarração entre deploy e comportamento em produção é o que mais reduz tempo de diagnóstico no dia a dia. A pergunta que abre quase todo incidente é o que mudou. A resposta costuma estar no último release.

Correlação automática: o diferencial real

Se houvesse uma única razão para pagar por uma plataforma integrada em vez de montar a própria, seria esta. Quando um alerta dispara, os sinais já chegam juntos.

O trace da requisição lenta vem acompanhado dos logs daquele exato container, no exato intervalo, mais as métricas do host que o executa e as mudanças de deploy recentes. Nada disso exigiu configuração: o vínculo vem do inventário e das tags.

Uma stack montada em casa alcança o mesmo resultado, mas com trabalho dedicado de integração: correlacionar identificadores entre ferramentas, padronizar tags e manter esse acordo vivo a cada serviço novo.

É por isso que a conversa sobre substituir o Datadog raramente é sobre funcionalidade isolada. Cada peça tem equivalente open source; o que custa reconstruir é a costura entre elas.

IA na plataforma: Watchdog e Bits AI

O Watchdog observa as séries temporais e sinaliza desvios sem que você defina limiares. Ele aprende o padrão de cada métrica e avisa quando o comportamento sai da faixa esperada, incluindo sazonalidade de dia e de semana.

O valor aparece nos casos que ninguém pensou em alertar. Um endpoint secundário que degradou depois de um deploy costuma passar despercebido por qualquer regra escrita à mão, porque ninguém escreve regra para o que não imaginou.

O Bits AI atua como camada conversacional sobre esse acervo. A proposta é perguntar em linguagem natural o que está acontecendo e receber a investigação já correlacionada, em vez de navegar entre painéis.

Como toda camada de IA aplicada a operações, o resultado depende da qualidade do que está embaixo. Tags inconsistentes e serviços sem dono produzem respostas confiantes e erradas, que é o pior defeito possível em um plantão.

Segurança, Cloud Cost e observabilidade de IA

A frente de segurança cobre postura de nuvem, detecção de ameaças em tempo de execução, varredura de vulnerabilidades em código e identificação de dados sensíveis trafegando em logs.

O módulo de custo de nuvem traz a fatura dos provedores para dentro da mesma interface, ligando gasto a serviço e a equipe. A ideia é responder quanto custa rodar determinado serviço com o mesmo recorte de tags que já organiza a telemetria.

Há também um módulo para observabilidade de LLMs, que rastreia chamadas a modelos de linguagem com latência, consumo de tokens, custo por requisição e qualidade da resposta.

O padrão se repete em todos eles: a capacidade existe, funciona bem e é cobrada à parte. A decisão de ligar um módulo novo é sempre também uma decisão de orçamento.

Como os dados chegam à plataforma

São três caminhos, e saber qual é qual muda a conversa sobre esforço de adoção. O primeiro é o agente instalado no host, que coleta métricas, logs e traces localmente e os envia. É o único que exige acesso à máquina.

O segundo é a integração por credencial, em que a plataforma lê as APIs do provedor de nuvem sem instalar nada em lugar nenhum. Cobre AWS, Azure e GCP, e é o caminho mais rápido para ter o primeiro painel de pé.

O terceiro é a biblioteca de instrumentação, adicionada ao código da aplicação. É a única forma de obter trace de verdade, com o caminho da requisição entre serviços, e a que exige trabalho do time de desenvolvimento. Também é a que amarra você à plataforma, se não usar padrão aberto.

O agente aceita configuração declarativa, o que permite tratá-lo como código e distribuí-lo pela mesma ferramenta que já provisiona o restante do ambiente. A documentação oficial detalha os parâmetros de cada modo de coleta.

Vale conhecer o suporte a OpenTelemetry antes de instrumentar. Usar o padrão aberto na instrumentação da aplicação preserva a opção de trocar de destino depois, sem reinstrumentar o código inteiro.

Essa escolha parece técnica e é estratégica. Instrumentação proprietária é o que transforma uma migração futura em reescrita.

Quando o Datadog faz sentido e quando não faz

Faz sentido quando o time é pequeno em relação ao ambiente e o tempo de engenharia vale mais que a mensalidade. Também faz sentido em ambientes majoritariamente em nuvem, efêmeros e heterogêneos, onde manter uma stack própria consome gente que você não tem.

E faz sentido quando o custo de um incidente longo é alto o bastante para justificar o prêmio da correlação pronta. Em operações que perdem receita por minuto, a diferença entre diagnosticar em cinco minutos ou em quarenta paga a diferença de licença.

Faz menos sentido em ambiente estável e previsível, com muitos hosts de longa duração e pouca variação. Aí o modelo por host cobra caro por uma elasticidade que você não usa.

Também pesa contra quando há exigência de dado em território nacional, quando o volume de logs é muito alto e pouco seletivo, ou quando já existe equipe de plataforma madura operando a stack própria. Nesses casos vale medir as alternativas ao Datadog antes de renovar.

A leitura honesta é que a plataforma é excelente e cara. As duas coisas são verdadeiras ao mesmo tempo. A pergunta certa não é se ela é boa. É se o perfil do seu ambiente aproveita aquilo que você está pagando.

O erro de avaliação mais comum

Comparar o preço de lista do Datadog com o custo de licença de uma stack open source, que é zero, para encerrar a análise ali. A conta que interessa inclui as pessoas que operam a stack, o armazenamento, a alta disponibilidade e o tempo de integração.

O inverso também acontece. Times contratam a plataforma inteira no primeiro dia, ligam todos os módulos e descobrem no terceiro mês que pagam por capacidades que ninguém abriu. Começar por infraestrutura e APM, ligando o resto conforme a necessidade aparece, evita esse desperdício.

Conclusão

O Datadog resolve em horas um problema que uma stack própria leva meses para costurar: ver logs, métricas, traces e infraestrutura no mesmo lugar, já correlacionados, sem trabalho manual de integração.

A contrapartida é um modelo de cobrança modular que precisa ser entendido antes da assinatura, não depois. Métricas customizadas e volume de logs são as duas alavancas que mais deslocam a fatura. Ambas crescem por decisões técnicas do dia a dia, longe de quem aprova o contrato.

Quem entra sabendo disso costuma extrair muito valor da plataforma. Quem entra atraído pela facilidade e descobre a conta no terceiro trimestre costuma virar cliente de projeto de redução de custo ou de migração.

Se a sua equipe está avaliando adotar, dimensionar ou reduzir o custo de um ambiente Datadog, a OpServices faz assessment, implementação e sustentação da plataforma com equipe dedicada.