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

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado ago/2026

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

Essa conveniência tem preço. É esse preço que mais surpreende quem contrata. Vale dizer que o licenciamento é modular: cada capacidade tem a própria unidade de cobrança. Um host monitorado sai por US$ 15 no plano Pro anual. O mesmo host com aplicação instrumentada passa de US$ 46 antes de qualquer log entrar na conta.

Este guia percorre o que a plataforma faz, módulo por módulo, como cada um é cobrado e em que cenários ela compensa. Além disso, os preços vêm da tabela oficial lida em 4 de setembro de 2026, com simulação de conta mensal em dois portes.

O que é o Datadog

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

Lançada em 2010 como serviço de monitoramento de infraestrutura em nuvem, a plataforma cresceu até cobrir a cadeia inteira. Isto é: 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. No entanto, 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. Por outro lado, o limite é a soberania do dado e o custo, que crescem junto com o volume enviado.

Vale ver a plataforma em uso antes de seguir. O tour abaixo a percorre inteira, módulo por módulo. Ao todo são 45 minutos em capítulos, portanto 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. Vale destacar que as unidades não se parecem entre si.

Cobra-se a infraestrutura por host monitorado, por mês. Já os logs vêm em duas etapas separadas: a ingestão por volume e a retenção por período. Do mesmo modo, o APM sai por host de aplicação, com limite de spans incluído e cobrança acima dele.

Testes sintéticos saem por execução. O monitoramento de usuário real sai por sessão. A segurança em nuvem sai por host. Inclusive quem só olha painel costuma ter licença própria.

A tabela abaixo reúne os módulos que aparecem em praticamente toda conta, com a unidade de cobrança de cada um. Todos os valores vêm da tabela oficial, lida em 4 de setembro de 2026.

Duas colunas merecem atenção. A primeira é a diferença entre anual e sob demanda. Sem compromisso de doze meses, o host sai por US$ 18 em vez de US$ 15. Em seguida vem a franquia, contada por host e não por conta.

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. Dessa forma, uma operação de porte médio aciona oito ou dez medidores sem perceber, cada um com a própria elasticidade.

Quanto custa na prática: dois cenários

Preço de tabela isolado não diz muito. Por isso, montamos abaixo duas contas com os valores acima, uma de porte médio e outra enxuta. Ambas assumem plano Pro e retenção de 15 dias nos logs.

Três leituras saem daí. Sem o compromisso de doze meses, a conta do porte médio sobe 25,1%, o equivalente a US$ 4.011 no ano. Além disso, os containers fora da franquia respondem por 21% da fatura mensal, mais que a linha inteira de logs. E o APM, contratado em menos de um terço dos hosts, já custa mais da metade da linha de infraestrutura.

Vale dizer que os dois cenários usam volumes conservadores. A Datadog não tem região no Brasil, portanto não existe preço local. A cobrança sai em dólar. Além disso, a variação cambial entra na conta antes de qualquer crescimento de ambiente.

O que acontece quando você passa do contratado

Cada plano embute uma franquia e cobra o excedente à parte. Por exemplo, o de infraestrutura inclui um número fixo de métricas customizadas e de containers por host. Acima disso, o container passa a ser cobrado por hora e a 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. O que passa disso vira cobrança por milhão de eventos. Ainda assim, não há corte de serviço quando o limite estoura. Isso é conveniente na operação e perigoso no orçamento, porque 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. Logo, o total cresce por multiplicação, não por soma.

Vale fazer a conta. Uma métrica com cinco tags de dez valores cada gera 100 mil séries temporais, porque as combinações se multiplicam. A franquia da conta de 40 hosts do cenário acima é de 4 mil métricas, ou seja, 100 por host. Uma única métrica mal etiquetada passa a franquia inteira em 25 vezes.

O time acha que criou uma métrica; a fatura registra um universo delas. É justamente o efeito que tratamos em cardinalidade de métricas.

E aqui está o detalhe que muda a avaliação: a Datadog não publica o preço unitário do excedente de métrica customizada. A página de preços informa a franquia por host e diz que o que passa dela é cobrado conforme o uso, sem tarifa de tabela. Todos os outros medidores têm preço aberto, inclusive o container, que sai por US$ 0,002 a hora.

Portanto, o item que mais estoura a conta é justamente o único que você não consegue estimar antes de contratar. Na negociação, é a primeira pergunta a fazer.

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 depois de um deploy dobra a linha de logs do mês. E ninguém mudou 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. Em seguida, apresenta tudo num mapa em que cada quadrado é uma máquina e a cor indica o estado.

Para containers, a leitura muda de granularidade. A plataforma trata o container como unidade efêmera e agrega por serviço, deployment ou namespace. Nesse sentido, é 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á ainda varredura de imagens em busca de vulnerabilidades conhecidas, ligando o inventário de containers ao catálogo de CVEs.

Assim, esse inventário é 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 juntaria os sinais sozinho.

Dashboards, monitores e gestão de incidentes

Cada integração ativada traz painéis prontos, com as métricas daquela tecnologia já dispostas. Assim, resolve-se o problema de folha em branco que trava a adoção de qualquer ferramenta de monitoramento nas primeiras semanas.

Monitores são as regras de alerta. Eles observam uma métrica, uma consulta em logs, o resultado de um teste sintético ou, inclusive, a combinação de vários numa condição composta.

Aqui aparece um detalhe de custo que passa despercebido: monitores que avaliam consultas complexas sobre janelas longas consomem recursos cobrados. Consequentemente, 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 e escalona quando ninguém reconhece o chamado. Ao mesmo tempo, agrupa sinais relacionados num incidente único e publica uma página de status.

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 registra cada requisição como um trace. Isto é, o caminho completo entre serviços e o tempo gasto em cada etapa.

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

O Service Map nasce desses traces, sem desenho manual. A plataforma infere quem chama quem e monta o grafo de dependências. Dessa forma, ele 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. Ao contrário, é o retrato do que está acontecendo em produção, que é o que vale na hora do incidente.

Logs, RUM e testes sintéticos

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. Assim, o resto fica disponível apenas por poucos dias.

Vale destacar que esse controle importa mais do que parece. Como a cobrança separa ingestão de retenção, a pipeline bem configurada acaba sendo 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. A saber: tempo de carregamento, erros de JavaScript, travamentos e o caminho percorrido antes do problema.

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. Por isso 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. Logo, é ele que responde se a lentidão está na aplicação ou no caminho até 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. Do mesmo modo, origem e destino saem identificados pelas mesmas tags do resto da plataforma.

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

Na entrega de software, a plataforma observa os pipelines de integração contínua: duração de cada etapa, testes instáveis e taxa de falha por branch. Dessa forma, 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. Vale destacar que a pergunta que abre quase todo incidente é o que mudou. E 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. Ou seja: quando um alerta dispara, os sinais já chegam juntos.

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

Uma stack montada em casa alcança o mesmo resultado, mas com trabalho dedicado de integração. A saber: 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. Inclusive a sazonalidade de dia e de semana entra na conta.

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

Já o Bits AI atua como camada conversacional sobre esse acervo. Vale dizer que a proposta é perguntar em linguagem natural o que está acontecendo. A investigação chega já correlacionada, em vez de exigir navegação entre painéis.

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

Segurança, Cloud Cost e observabilidade de IA

A frente de segurança cobre quatro coisas. A saber: postura de nuvem, detecção de ameaças em tempo de execução, varredura de vulnerabilidades em código e identificação de dado sensível em logs.

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

Há ainda um módulo para observabilidade de LLMs. Ele 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 sai cobrada à parte. Portanto, ligar um módulo novo é sempre também uma decisão de orçamento.

Como os dados chegam à plataforma

São três caminhos. 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. Por conseguinte, é 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. Ela cobre AWS, Azure e GCP. Consequentemente, é 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. Em contrapartida, exige trabalho do time de desenvolvimento. E amarra você à plataforma, caso não use padrão aberto.

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

Vale conhecer o suporte a OpenTelemetry antes de instrumentar. Isto é: usar o padrão aberto preserva a opção de trocar de destino depois, sem reinstrumentar o código inteiro.

Essa escolha parece técnica e é estratégica. Isto é, instrumentação proprietária 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. Do mesmo modo, faz sentido em ambiente majoritariamente em nuvem, efêmero e heterogêneo, onde manter 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. Por exemplo, em operações que perdem receita por minuto, diagnosticar em cinco minutos em vez de quarenta já paga a licença.

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

Também pesa contra em três situações. A saber: exigência de dado em território nacional, volume de logs alto e pouco seletivo, ou equipe de plataforma madura já operando. Nesses casos, vale medir as alternativas ao Datadog antes de renovar.

A leitura honesta é que a plataforma é excelente e cara. Ambas as coisas são verdadeiras ao mesmo tempo. Portanto, a pergunta certa não é se ela é boa. É se o perfil do seu ambiente aproveita aquilo que você paga.

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. No entanto, 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. Em contrapartida, times contratam a plataforma inteira no primeiro dia e ligam todos os módulos. No terceiro mês, descobrem 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. Ou seja: ver logs, métricas, traces e infraestrutura no mesmo lugar, já correlacionados, sem integração manual.

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.

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.