Como monitorar banco de dados: pg_stat_statements, Performance Schema e PMM

Monitore MySQL, MariaDB e PostgreSQL: ative pg_stat_statements e Performance Schema, ache as consultas mais caras e instale o PMM com painéis e alertas.

Para que serve

Sem dados históricos, qualquer lentidão vira adivinhação. Para monitorar banco de dados de forma útil você precisa de duas coisas: estatísticas por consulta (quais consultas consomem mais tempo no total) e métricas ao longo do tempo (conexões, cache, disco, atraso de réplica). Este artigo ativa o pg_stat_statements no PostgreSQL, usa o Performance Schema no MySQL/MariaDB e instala o PMM (Percona Monitoring and Management), ferramenta gratuita com painéis Grafana prontos.

Sem o serviço de Gerenciamento contratado, o monitoramento do banco é responsabilidade do cliente. O que segue é suficiente para ter visibilidade e alertas básicos.

Pré-requisitos

• Acesso root ao servidor/VM do banco e usuário administrativo no banco.
• Para o PMM: uma VM ou container com Docker, 2 vCPUs, 4 GB de RAM e algumas dezenas de GB de disco (mais conforme o número de bancos monitorados).
• Uma janela para reiniciar o PostgreSQL (ativar o pg_stat_statements exige restart).

1. PostgreSQL: ative o pg_stat_statements

cat > /etc/postgresql/17/main/conf.d/93-monitoramento.conf <<'EOF'
shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.max = 10000
pg_stat_statements.track = top
track_io_timing = on
EOF
systemctl restart postgresql@17-main
sudo -u postgres psql -d appdb -c "CREATE EXTENSION IF NOT EXISTS pg_stat_statements;"

Se o shared_preload_libraries já tiver outro valor, junte os nomes separados por vírgula. O track_io_timing tem custo baixo em hardware atual; para conferir, rode pg_test_timing.

As consultas que mais consomem tempo no total:

SELECT round(total_exec_time::numeric/1000, 1) AS total_s,
       calls,
       round(mean_exec_time::numeric, 2) AS media_ms,
       rows,
       round(100.0*shared_blks_hit/nullif(shared_blks_hit+shared_blks_read,0),1) AS cache_pct,
       left(query, 100) AS consulta
FROM pg_stat_statements
ORDER BY total_exec_time DESC LIMIT 15;

Leia assim: total_s alto com media_ms baixo é uma consulta rápida executada milhões de vezes (cache na aplicação ou índice de cobertura ajudam); media_ms alto é uma consulta individualmente pesada (veja o artigo sobre índices). cache_pct baixo indica leitura de disco.

Para medir o efeito de uma correção, zere as estatísticas antes e compare depois: SELECT pg_stat_statements_reset();.

Outras visões úteis do PostgreSQL:

• pg_stat_activity: sessões atuais e o que esperam (wait_event_type).
• pg_stat_database: commits, rollbacks, cache hit, arquivos temporários, deadlocks.
• pg_stat_user_tables: varreduras sequenciais e tuplas mortas (veja autovacuum e bloat).
• pg_stat_replication: atraso das réplicas.

2. MySQL e MariaDB: use o Performance Schema

No MySQL 8 o Performance Schema já vem ligado. No MariaDB ele vem desligado; ative no 50-server.cnf e reinicie:

[mysqld]
performance_schema = ON

Confira com SHOW VARIABLES LIKE 'performance_schema';. O consumo extra de memória é de algumas centenas de MB, aceitável em servidores com bastante RAM.

As consultas mais caras, agrupadas por formato (digest):

SELECT query, db, exec_count, total_latency, avg_latency,
       rows_examined_avg, rows_sent_avg, full_scan
FROM sys.statement_analysis
ORDER BY total_latency DESC LIMIT 15;

Sem o schema sys, use a tabela de origem (tempos em picossegundos):

SELECT digest_text, count_star,
       round(sum_timer_wait/1e12, 1) AS total_s,
       round(avg_timer_wait/1e9, 2)  AS media_ms,
       sum_rows_examined, sum_no_index_used
FROM performance_schema.events_statements_summary_by_digest
ORDER BY sum_timer_wait DESC LIMIT 15;

Outras visões úteis do sys: sys.host_summary, sys.io_global_by_file_by_latency, sys.schema_table_statistics, sys.innodb_lock_waits. Para análise pontual de lentidão via arquivo, veja MySQL lento: slow query log e EXPLAIN.

3. Instale o PMM para histórico, painéis e alertas

O PMM tem duas partes: o PMM Server (Grafana, banco de métricas e analisador de consultas) e o PMM Client, instalado em cada servidor de banco.

PMM Server em Docker

Em uma VM separada do banco (pode ser no mesmo Proxmox), com Docker instalado:

docker volume create pmm-data
docker run -d --restart always --name pmm-server \
  -p 443:8443 -v pmm-data:/srv percona/pmm-server:3

Acesse https://IP-DA-VM, entre com admin/admin e troque a senha no primeiro login.

PMM Client no servidor do banco (Debian/Ubuntu)

wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
dpkg -i percona-release_latest.generic_all.deb
percona-release enable pmm3-client release
apt update && apt install -y pmm-client
pmm-admin config --server-insecure-tls \
  --server-url=https://admin:SENHA@10.0.0.50:443

Se houver firewall entre eles, libere a porta 443 do PMM Server para os IPs dos clientes. Por padrão, o cliente envia as métricas ao servidor por essa conexão.

Adicione o MySQL/MariaDB

CREATE USER 'pmm'@'127.0.0.1' IDENTIFIED BY 'SenhaPMM' WITH MAX_USER_CONNECTIONS 10;
GRANT SELECT, PROCESS, REPLICATION CLIENT, RELOAD ON *.* TO 'pmm'@'127.0.0.1';
-- MySQL 8: GRANT BACKUP_ADMIN ON *.* TO 'pmm'@'127.0.0.1';

pmm-admin add mysql --query-source=perfschema \
  --username=pmm --password=SenhaPMM --host=127.0.0.1 --port=3306

Adicione o PostgreSQL

A documentação do PMM usa um usuário dedicado com privilégio de superusuário, restrito a conexões locais no pg_hba.conf:

sudo -u postgres psql -c "CREATE USER pmm WITH SUPERUSER ENCRYPTED PASSWORD 'SenhaPMM';"
# pg_hba.conf, antes das outras linhas:
# host  all  pmm  127.0.0.1/32  scram-sha-256
pmm-admin add postgresql --query-source=pgstatements \
  --username=pmm --password=SenhaPMM --host=127.0.0.1 --port=5432

O PMM também aceita a extensão pg_stat_monitor da Percona como fonte de consultas, com mais detalhes; o pg_stat_statements configurado no passo 1 já atende.

4. O que acompanhar ao monitorar banco de dados

O PMM traz regras de alerta prontas (menu Alerting) que podem enviar e-mail, Telegram ou webhook. Se você já usa Zabbix, Prometheus ou Netdata, os exporters mysqld_exporter e postgres_exporter e os templates oficiais cobrem as mesmas métricas.

Como saber se funcionou

• SELECT count(*) FROM pg_stat_statements; retorna linhas, e SELECT count(*) FROM performance_schema.events_statements_summary_by_digest; também.
• pmm-admin list mostra os serviços com status Running.
• No PMM, o painel MySQL Instance Summary ou PostgreSQL Instance Summary exibe gráficos, e Query Analytics (QAN) lista as consultas.

Problemas comuns

"pg_stat_statements must be loaded via shared_preload_libraries"

O parâmetro não foi aplicado: reinicie o serviço (reload não basta) e confira com SHOW shared_preload_libraries;.

Query Analytics vazio no PMM

Fonte de consultas errada ou extensão não criada no banco monitorado. Confira com pmm-admin list e crie a extensão no banco usado na conexão.

O cliente não conecta ao PMM Server

Teste curl -k https://10.0.0.50 a partir do servidor do banco. Se falhar, revise rotas e firewall.

Perguntas frequentes

O pg_stat_statements deixa o PostgreSQL mais lento?

O custo é baixo e amplamente aceito em produção. O benefício de saber quais consultas pesam supera com folga.

O PMM é pago?

Não. É software livre da Percona e pode ser usado sem custo; há suporte comercial opcional do próprio fabricante.

Posso monitorar SQL Server com o PMM?

Não nativamente. Para SQL Server, use as DMVs, o Query Store (ative com ALTER DATABASE MeuBanco SET QUERY_STORE = ON;) e ferramentas como Zabbix com o template de MSSQL.

Leitura complementar

• PostgreSQL: pg_stat_statements
• MySQL 8.4: Performance Schema
• Percona: PMM 3 Quickstart

Precisa de ajuda?

Se os gráficos indicarem problema de hardware (latência de disco alta sem aumento de carga, erros de memória), abra um ticket com prints dos painéis e o horário do evento.