Melhores Práticas de Monitoramento
Um bom monitoramento do PostgreSQL informa à equipe de plantão se os usuários estão sendo afetados e onde procurar primeiro. Estas regras mantêm o sinal alto e a fadiga de pagers baixa em implantações auto-hospedadas e gerenciadas.
Como Usar Esta Lista
- Aplique ao configurar um novo cluster ou refatorar alertas barulhentos
- Combine com postgres_exporter & Grafana para implementação
- Revise trimestralmente em relação aos últimos três incidentes: as métricas mostraram a causa raiz?
A - Fundações
- pg_stat_statements habilitado com shared_preload_libraries. Consultas principais por tempo total exportadas ou revisadas semanalmente.
- Função de monitoramento dedicada com pg_monitor. O exporter não usa superusuário.
- Métricas do host junto com métricas do banco de dados. CPU, iowait, disco livre, rede na mesma linha do painel.
- Linha de base registrada após a implantação. Conexões, lag, 5 principais consultas documentadas no ticket de lançamento.
- Métricas do pool PgBouncer se estiver usando pool.
cl_waitingalerta antes domax_connectionsdo Postgres.
B - Alertas (Priorizando Sintomas)
- Conexões acima de 80% de max_connections. Aviso; 90% página.
- Lag de replicação acima do orçamento de RPO. Bytes e segundos, por standby.
- Disco acima de 85% nos volumes de dados e WAL. Página com link para o runbook.
- Pico na taxa de deadlock vs mediana de 7 dias. Não um único deadlock.
- Longas esperas de bloqueio (>30s) em tabelas críticas. SQL personalizado ou
log_lock_waits. - Evite paginar apenas por checkpoint ou autovacuum. Painéis de contexto, não páginas autônomas.
C - Dashboards
- Um dashboard de visão geral por ambiente. Produção/staging distintos; mesmo layout.
- Painel de SLO voltado para o usuário do APM. Latência p95 com span de dependência do banco de dados.
- Painel de detalhamento de wait_event. Bloqueio vs IO vs Cliente durante incidentes.
- Gráfico de lag de slots de replicação. Evite que o disco WAL encha devido a slots desatualizados.
- Anotações para implantações e manutenção. Correlacione regressões rapidamente.
D - Processo
- Revisão semanal de métricas de 15 minutos. Principais consultas e tendência de conexão sem incidentes.
- Alerta testado em staging trimestralmente. Verifique o roteamento de notificação.
- Link do runbook em cada página. Passos de triagem de
pg_stat_activityanexados. - Ticket de lacuna de métricas pós-incidente. Painel ausente adicionado em duas sprints.
- Política de redefinição de estatísticas documentada.
pg_stat_statements_resetapenas após grandes lançamentos.
FAQs
Quantos alertas são suficientes?
Comece com 5-8. Adicione quando um incidente foi cego, não preventivamente para cada medidor.
RDS Gerenciado ainda precisa disso?
Sim para carga de trabalho de consulta e correlação de aplicativos. O CloudWatch sozinho não classifica pg_stat_statements.
Quem é alertado?
Rotação de plataforma para saturação de infraestrutura; plantão de aplicativo para queima de SLO com transferência de detalhamento do banco de dados.
Logs ou métricas primeiro?
Métricas para paginação; logs para forense após ponteiro do painel.
Monitoramento sintético?
Caminho de escrita/leitura de canário a cada 1m complementa as métricas; não é um substituto.
Explosão de cardinalidade?
Nunca rotule métricas do Prometheus com texto de consulta ou ID do usuário.
Dashboards de réplica de leitura?
Linha separada para lag de replay e contagens de conflito; não mescle cegamente com TPS primário.
Bancos de dados de desenvolvimento?
Monitore apenas a disponibilidade; sem roteamento de alertas de produção.
Visão do comandante do incidente?
Painel único: sessões ativas, esperas de bloqueio, lag, disco - otimizado para compartilhamento de tela.
Controle de custo no APM SaaS?
Amostre traces de alta cardinalidade; mantenha métricas de banco de dados no Prometheus para retenção barata.
Relacionados
- Noções Básicas de Monitoramento - sinais principais
- pg_stat_activity & Locks - triagem ao vivo
- pg_stat_statements - classificação de consultas
- Dashboards de SLO - orçamentos de usuários
- Noções Básicas de Incidentes - fluxo de resposta
Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.