Datadog para Bancos de Dados: Guia Completo de Database Monitoring

O que é o Datadog Database Monitoring?

O Datadog Database Monitoring (DBM) é um módulo da plataforma de observabilidade Datadog focado em fornecer visibilidade profunda e em tempo real sobre o desempenho de bancos de dados relacionais e NoSQL. Ele vai muito além do monitoramento tradicional de infraestrutura, permitindo que engenheiros e DBAs identifiquem, investiguem e resolvam gargalos em queries antes que eles impactem o usuário final.

Ao contrário de soluções que apenas monitoram métricas de host (CPU, memória, disco), o DBM desce ao nível da query, exibindo:

• Quais queries estão consumindo mais recursos
• O plano de execução exato de cada query
• Quais queries estão bloqueando outras
• Correlação entre performance de banco e comportamento da aplicação

Em resumo: o DBM transforma dados brutos de banco de dados em insights acionáveis, acelerando drasticamente o processo de troubleshooting.

Principais Funcionalidades

1. Query Metrics View

A visão de Query Metrics exibe o desempenho histórico de queries normalizadas. Com ela, é possível:

• Visualizar tendências de performance ao longo do tempo
• Filtrar e agrupar queries por team, user, cluster, host ou qualquer tag customizada
• Identificar queries lentas e as que mais consomem tempo de execução total
• Acessar métricas específicas do banco, como linhas atualizadas/retornadas, não capturadas pelo APM tradicional

2. Query Samples

O Query Samples mostra um snapshot das queries executadas em um determinado intervalo de tempo. Útil para:

• Entender o comportamento transacional do banco em picos de carga
• Correlacionar queries específicas com eventos de incidente
• Identificar padrões de uso anômalos

3. Explain Plans

Para cada query, o DBM captura automaticamente o plano de execução (EXPLAIN PLAN), que detalha:

• Os passos executados pelo otimizador do banco
• Custo estimado de cada operação
• Operações ineficientes, como Sequential Scans que poderiam ser substituídos por índices

4. Wait Event Analysis

A análise de Wait Events (eventos de espera) permite:

• Identificar por quê queries estão demorando (aguardando lock, I/O, CPU, rede)
• Visualizar a carga do banco por tipo de espera
• Entender quais usuários, queries e serviços estão gerando mais carga

5. Blocking Queries

O DBM detecta e exibe automaticamente queries que estão bloqueando outras, mostrando a cadeia completa de bloqueio — um diferencial crítico para ambientes OLTP de alta concorrência.

Arquitetura e Funcionamento

O DBM utiliza o Datadog Agent instalado no host do banco (ou em um host separado, para serviços gerenciados). O Agent conecta ao banco como um usuário read-only e coleta telemetria diretamente:

┌─────────────────────────────────────┐
│         Aplicação / Backend         │
└───────────────┬─────────────────────┘
                │ queries
                ▼
┌─────────────────────────────────────┐
│         Banco de Dados              │
│  (PostgreSQL / MySQL / etc.)        │
│                                     │
│  pg_stat_statements                 │
│  pg_stat_activity                   │
│  auto_explain                       │
└───────────────┬─────────────────────┘
                │ métricas (read-only)
                ▼
┌─────────────────────────────────────┐
│         Datadog Agent               │
│  (instalado no host ou remoto)      │
└───────────────┬─────────────────────┘
                │ HTTPS / TLS
                ▼
┌─────────────────────────────────────┐
│         Datadog Platform            │
│  DBM · APM · Logs · Dashboards      │
└─────────────────────────────────────┘

Importante: O Agent não deve se conectar ao banco via proxy, load balancer ou connection pooler (como PgBouncer), pois isso pode gerar métricas imprecisas ao apontar para hosts diferentes.

Configuração Passo a Passo: PostgreSQL

Pré-requisitos

• Datadog Agent v7.36.1+
• PostgreSQL v9.6 ou superior
• Extensão pg_stat_statements instalada
• Módulo postgresql-contrib disponível

Passo 1 — Configurar o PostgreSQL

Edite o arquivo postgresql.conf:

# Habilita rastreamento de statements
shared_preload_libraries = 'pg_stat_statements,auto_explain'

# Configurações do pg_stat_statements
pg_stat_statements.max = 10000
pg_stat_statements.track = all
pg_stat_statements.track_utility = false
pg_stat_statements.save = true

# Configurações do auto_explain (planos de execução automáticos)
auto_explain.log_min_duration = '500ms'
auto_explain.log_analyze = true
auto_explain.log_format = json
auto_explain.log_timing = false
auto_explain.sample_rate = 0.05

Após editar, reinicie o servidor PostgreSQL:

sudo systemctl restart postgresql

Passo 2 — Criar o usuário Datadog no banco

Conecte via psql com um usuário com privilégios de CREATEROLE:

-- Criar usuário read-only para o Datadog Agent
CREATE USER datadog WITH PASSWORD 'SUA_SENHA_SEGURA';

-- Conceder permissões de monitoramento (PostgreSQL 10+)
GRANT pg_monitor TO datadog;

-- Conceder acesso às estatísticas de banco
GRANT SELECT ON pg_stat_database TO datadog;

Para coletar métricas customizadas de tabelas específicas:

GRANT SELECT ON <NOME_DA_TABELA> TO datadog;

Valide a conexão:

psql -h localhost -U datadog postgres -c \
  "SELECT * FROM pg_stat_database LIMIT 1;" \
  && echo "Conexão OK" \
  || echo " Falha na conexão"

Passo 3 — Configurar o Datadog Agent

Crie ou edite o arquivo /etc/datadog-agent/conf.d/postgres.d/conf.yaml:

init_config:

instances:
  - host: 127.0.0.1
    port: 5432
    username: datadog
    password: SUA_SENHA_SEGURA
    dbname: postgres

    # Habilita o Database Monitoring
    dbm: true

    # Coleta de métricas de tamanho do banco
    # Desabilite em instâncias com milhares de relações
    collect_database_size_metrics: true

    # Intervalo de coleta em segundos (padrão: 1s)
    collection_interval: 1

    # Tags customizadas para filtros no dashboard
    tags:
      - env:production
      - team:backend
      - service:meu-servico

Reinicie o Agent:

sudo systemctl restart datadog-agent

# Verifique o status
sudo datadog-agent status | grep -A 20 "postgres"

Passo 4 — Habilitar coleta de logs (opcional, mas recomendado)

No arquivo /etc/datadog-agent/datadog.yaml:

logs_enabled: true

No arquivo de configuração do PostgreSQL (postgresql.conf):

logging_collector = on
log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_statement = 'all'
log_min_duration_statement = 500  # loga queries acima de 500ms
log_line_prefix = '%m [%p] %q%u@%d '

Configuração Passo a Passo: MySQL

Passo 1 — Configurar o MySQL

Edite o my.cnf ou my.ini:

[mysqld]
# Habilita Performance Schema
performance_schema = ON
performance-schema-consumer-events-statements-current = ON
performance-schema-consumer-events-waits-current = ON

# Habilita slow query log
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.5
log_queries_not_using_indexes = ON

Passo 2 — Criar o usuário Datadog no MySQL

-- MySQL 8.0+
CREATE USER 'datadog'@'%' IDENTIFIED BY 'SUA_SENHA_SEGURA';

-- Permissões necessárias para DBM
GRANT REPLICATION CLIENT ON *.* TO 'datadog'@'%';
GRANT PROCESS ON *.* TO 'datadog'@'%';
GRANT SELECT ON performance_schema.* TO 'datadog'@'%';

-- Para explain plans automáticos
GRANT SELECT ON sys.* TO 'datadog'@'%';

FLUSH PRIVILEGES;

Passo 3 — Configurar o Datadog Agent para MySQL

Crie /etc/datadog-agent/conf.d/mysql.d/conf.yaml:

init_config:

instances:
  - host: 127.0.0.1
    port: 3306
    username: datadog
    password: SUA_SENHA_SEGURA

    # Habilita o Database Monitoring
    dbm: true

    # Coleta de explain plans
    collect_explain_plans: true

    # Tags
    tags:
      - env:production
      - team:backend

Métricas Essenciais para Monitorar

PostgreSQL

MySQL

Alertas e Monitores

Criando um monitor para queries lentas (exemplo via Terraform)

resource "datadog_monitor" "slow_queries" {
  name    = "[PostgreSQL] Queries lentas acima de 2 segundos"
  type    = "metric alert"
  message = <<-EOT
    Queries com duração média acima de 2 segundos detectadas no banco {{host.name}}.
    
    Verifique o painel de Query Metrics no Datadog DBM para identificar as queries problemáticas.
    
    @pagerduty-database-oncall @slack-db-alerts
  EOT

  query = "avg(last_5m):avg:postgresql.queries.mean_time{env:production} by {host} > 2000"

  monitor_thresholds {
    critical = 2000  # 2000ms = 2s
    warning  = 1000  # 1000ms = 1s
  }

  notify_no_data    = false
  renotify_interval = 30

  tags = ["env:production", "team:backend", "service:database"]
}

Monitor para taxa de cache hit

resource "datadog_monitor" "cache_hit_ratio" {
  name    = "[PostgreSQL] Cache Hit Ratio abaixo de 95%"
  type    = "metric alert"
  message = "@slack-db-alerts Cache hit ratio degradado — possível pressão de memória."

  query = "avg(last_10m):avg:postgresql.cache_hit{env:production} by {host} < 95"

  monitor_thresholds {
    critical = 90
    warning  = 95
  }
}

Monitor para conexões

resource "datadog_monitor" "connection_usage" {
  name    = "[PostgreSQL] Uso de conexões acima de 80%"
  type    = "metric alert"
  message = "@pagerduty-db Número de conexões se aproximando do limite máximo."

  query = "avg(last_5m):avg:postgresql.percent_usage_connections{env:production} by {host} > 80"

  monitor_thresholds {
    critical = 90
    warning  = 80
  }
}

Integração com APM

Uma das funcionalidades mais poderosas do Datadog DBM é a integração nativa com o APM (Application Performance Monitoring). Isso permite correlacionar uma query lenta diretamente com a requisição HTTP ou o trace de aplicação que a originou.

Como funciona

1. O APM instrumenta a aplicação (via SDK Datadog para Python, Java, Node.js, Go, Ruby, etc.)
2. O DBM captura as queries e seus metadados
3. O Datadog correlaciona automaticamente usando o trace ID propagado na query

Configurando a propagação de trace (exemplo em Python)

import psycopg2
from ddtrace import patch_all, tracer

# Instrumenta automaticamente o driver do PostgreSQL
patch_all()

@tracer.wrap(service="meu-servico", resource="buscar_usuarios")
def buscar_usuarios(filtro: str):
    conn = psycopg2.connect(
        host="localhost",
        database="meu_banco",
        user="app_user",
        password="senha"
    )
    cursor = conn.cursor()
    
    # O trace ID é automaticamente injetado como comentário SQL
    # pelo patch do ddtrace, permitindo correlação no DBM
    cursor.execute(
        "SELECT id, nome, email FROM usuarios WHERE status = %s LIMIT 100",
        (filtro,)
    )
    return cursor.fetchall()

Exemplo em Java (Spring Boot)

// Adicione a dependência no pom.xml:
// <dependency>
//   <groupId>com.datadoghq</groupId>
//   <artifactId>dd-trace-api</artifactId>
//   <version>1.x.x</version>
// </dependency>

// A instrumentação automática do JDBC injeta o trace ID nas queries
// Habilite no arquivo de propriedades da aplicação:
// dd.trace.db.client.split-by-instance=true
// dd.jdbc.prepared.statement.db.name.lookup=true

Com a integração configurada, ao identificar uma query lenta no painel DBM, você pode clicar diretamente no trace da aplicação que a originou — encurtando drasticamente o MTTR (Mean Time To Resolve).

Boas Práticas e Considerações de Segurança

Segurança

1. Princípio do menor privilégio
Sempre crie um usuário dedicado e read-only para o Datadog Agent. Nunca utilize o superusuário do banco.

-- PostgreSQL: apenas o necessário
GRANT pg_monitor TO datadog;
GRANT SELECT ON pg_stat_database TO datadog;

-- Não conceda: SUPERUSER, CREATEDB, CREATEROLE

2. Gerenciamento seguro de credenciais
Utilize variáveis de ambiente ou um secret manager (AWS Secrets Manager, HashiCorp Vault) em vez de hardcoded passwords no conf.yaml:

instances:
  - host: 127.0.0.1
    username: datadog
    password: ENC[datadog_secret:db_password]  # Integração com Datadog Secret Backend

3. Dados sensíveis em query samples
O DBM anonimiza automaticamente os valores nos parâmetros das queries (ex: SELECT * FROM users WHERE email = ?). Verifique se a opção de obfuscação está habilitada (padrão: ativo).

4. Controle de acesso via RBAC
Use as funcionalidades de RBAC do Datadog para restringir quem pode visualizar explain plans e query samples contendo dados potencialmente sensíveis.

Performance

1. Ajuste do intervalo de coleta
Para instâncias de alta carga, considere aumentar o collection_interval para reduzir overhead:

instances:
  - dbm: true
    collection_interval: 5  # Reduz frequência em bancos sobrecarregados

2. Bancos com muitas relações
Em instâncias PostgreSQL com milhares de tabelas, desabilite a coleta de tamanho para evitar queries pg_database_size() custosas:

instances:
  - dbm: true
    collect_database_size_metrics: false

3. Auto_explain e volume de logs
O auto_explain pode gerar grande volume de logs em bancos de alta carga. Ajuste auto_explain.log_min_duration e auto_explain.sample_rate conforme necessário:

auto_explain.log_min_duration = '1s'   # Apenas queries acima de 1 segundo
auto_explain.sample_rate = 0.01        # Amostrar 1% das queries elegíveis

Custos e Considerações de Adoção

O Datadog DBM é um produto pago, com precificação por host monitorado:

Nota: Preços são estimativas de mercado e podem variar. Consulte o site oficial do Datadog para valores atualizados e planos Enterprise.

Quando o DBM se paga?

O ROI do Datadog DBM é mais claro em cenários como:

• Incidentes de produção recorrentes causados por queries lentas ou bloqueios
• Times sem DBA dedicado, onde engenheiros de backend precisam investigar problemas de banco sozinhos
• Ambientes multi-banco e multi-cloud, onde a visibilidade unificada é crítica
• Alta sensibilidade a latência, como e-commerce, fintechs e SaaS B2B

Uma única hora de indisponibilidade evitada frequentemente supera meses do custo da ferramenta.

Conclusão

O Datadog Database Monitoring representa uma evolução significativa na capacidade de observabilidade sobre bancos de dados. Ao unir métricas de infraestrutura, análise de queries, planos de execução, wait events e correlação com traces de aplicação em uma única plataforma, o DBM elimina os silos tradicionais entre times de desenvolvimento, operações e DBA.

Os principais benefícios práticos são:

• Redução do MTTR em incidentes relacionados a banco de dados
• Proatividade na identificação de queries problemáticas antes que virem incidente
• Colaboração entre devs e DBAs com uma linguagem e visão comuns
• Otimização contínua de performance com dados históricos e explain plans automáticos

Para times que já utilizam o Datadog como plataforma de observabilidade, habilitar o DBM é um passo natural e de alto valor. Para quem está avaliando ferramentas, o trial gratuito de 14 dias permite validar o impacto no ambiente real antes da decisão de adoção.

Referências

• Documentação oficial: Datadog Database Monitoring
• Setup PostgreSQL Self-Hosted
• Configuração avançada PostgreSQL DBM
• Integração PostgreSQL padrão
• Pricing Datadog