Pontos-Chave de Monitoramento e Métricas
Monitorar um cluster PostgreSQL não se trata de coletar todos os números que o sistema expõe, mas sim de saber quais poucos números realmente preveem a dor do usuário.
//
Busque em todas as páginas da documentação
Monitorar um cluster PostgreSQL não se trata de coletar todos os números que o sistema expõe, mas sim de saber quais poucos números realmente preveem a dor do usuário.
Esta página constrói o modelo mental por trás desse filtragem: o que cada classe de sinal representa, como os sinais se relacionam entre si e como raciocinar de um sintoma para uma causa raiz em vez de olhar para uma parede de gráficos.
Todo sinal de monitoramento do PostgreSQL se enquadra em uma de um pequeno número de categorias: conexões, bloqueios, replicação, armazenamento/inchaço e carga de consulta.
Conexões descrevem o quão perto o cluster está de max_connections, um limite rígido a partir do qual novas sessões são simplesmente recusadas.
Bloqueios e eventos de espera descrevem se os backends estão trabalhando ativamente ou presos esperando por outra coisa, que é frequentemente a causa real por trás de uma reclamação de "lentidão".
Atraso de replicação mede o quão longe um standby ou assinante lógico ficou para trás do primário, o que é importante tanto para a atualidade dos dados de leitura quanto para a postura de recuperação de desastres.
Sinais de inchaço, principalmente contagens de tuplas mortas, descrevem se o autovacuum está acompanhando a carga de escrita ou perdendo terreno lentamente.
Métricas de carga de consulta, mais visivelmente de pg_stat_statements, descrevem quais consultas consomem mais tempo cumulativo do banco de dados em vez de qual execução única foi a mais lenta.
A ideia unificadora em todas as cinco categorias é que o PostgreSQL expõe esse estado diretamente através das visualizações de sistema pg_stat_*, então as ferramentas de monitoramento estão transmitindo dados que o banco de dados já rastreia, não inventando nova instrumentação.
Um atalho mental útil é tratar o monitoramento como a resposta a uma pergunta recorrente: alguém está esperando agora e, se sim, em qual recurso.
Conexões respondem "o novo trabalho pode sequer começar", bloqueios e eventos de espera respondem "por que o trabalho existente está preso", e o atraso de replicação responde "quão desatualizados são os dados que um leitor pode ver".
Esses sinais não existem independentemente, eles formam uma cadeia causal que operadores experientes leem em ordem durante um incidente.
Um pico na latência de consulta muitas vezes começa como um aumento na contenção de bloqueios, que aparece como backends se acumulando em pg_stat_activity com um wait_event não nulo.
Se essa contenção persistir, as conexões ativas se acumulam mais rápido do que se completam, empurrando o cluster em direção ao teto de max_connections e, eventualmente, fazendo com que novas conexões sejam rejeitadas.
Enquanto isso, se a carga de trabalho incluir transações de longa duração, o autovacuum fica para trás nas tabelas que essas transações tocam, e as contagens de tuplas mortas aumentam, o que degrada ainda mais os planos de consulta e pode agravar o problema original de latência.
O atraso de replicação tipicamente segue em vez de liderar essa cadeia, porque um primário ocupado gera WAL mais rápido do que um standby pode reproduzi-lo, então o atraso é frequentemente um sintoma downstream da mesma pressão de escrita que causa contenção de bloqueios.
-- Um mecanismo concretizado: wait_event é nulo enquanto um backend
-- está executando ativamente, e não nulo no momento em que está
-- bloqueado esperando por um bloqueio, I/O ou outro backend.
SELECT pid, state, wait_event_type, wait_event, query
FROM pg_stat_activity
WHERE state = 'active'
AND pid <> pg_backend_pid();Essa consulta é a etapa de triagem mais útil durante um incidente, porque uma coluna wait_event preenchida informa imediatamente se o banco de dados está fazendo trabalho real ou está preso, o que muda todo o caminho da investigação.
Um erro comum de raciocínio é observar apenas a utilização da CPU, pois as cargas de trabalho do PostgreSQL são frequentemente limitadas por esperas de bloqueio ou I/O de disco em vez de computação bruta, então um gráfico de CPU saudável pode coexistir com um cluster que está efetivamente congelado para os usuários.
Em escala, o monitoramento se estende além do próprio processo do banco de dados para o pooler de conexões, o host e a política de alerta que transforma métricas em páginas.
Um pooler de conexões como o PgBouncer introduz seu próprio ponto de saturação, cl_waiting, que pode aumentar enquanto a instância Postgres subjacente ainda tem capacidade, então as métricas do pooler precisam ser coletadas como um sinal distinto, não inferidas apenas de números do lado do banco de dados.
O design de alertas é em si uma decisão arquitetural: alertar sobre cada métrica que se desvia da linha de base produz fadiga e treina os respondedores a descartar páginas, enquanto alertar apenas sobre sintomas que os usuários realmente sentem, como exaustão de conexão ou atraso além de um orçamento acordado, mantém a relação sinal-ruído alta.
Linhas de base importam mais do que limites absolutos, porque "80% de CPU" significa algo diferente em um cluster que normalmente roda a 20% versus um que normalmente roda a 70%, então configurações maduras rastreiam as diferenças semana a semana juntamente com limites estáticos.
Plataformas PostgreSQL gerenciadas expõem seus próprios painéis de infraestrutura, mas esses painéis geralmente param na camada de host e instância, deixando a visibilidade em nível de consulta e de bloqueio como algo que a equipe de aplicação ainda precisa adicionar.
A retenção de métricas de longo prazo permite um tipo diferente de pergunta do que os painéis em tempo real, permitindo que as equipes correlacionem uma tendência de degradação lenta de inchaço com um deploy de três semanas atrás, em vez de apenas reagir ao momento em que um alerta dispara.
| Abordagem | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| postgres_exporter + Prometheus | Cobertura rica e padrão de pg_stat_* | Requer pilha de scrape/alerta auto-gerenciada | Clusters hospedados em Kubernetes ou VM |
| Painéis nativos da nuvem (CloudWatch, Cloud Monitoring) | Configuração zero, vinculado à instância gerenciada | Fraco em detalhes de nível de bloqueio/consulta | RDS, Cloud SQL e plataformas gerenciadas semelhantes |
Consultas ad hoc pg_stat_statements | Imediato, sem infra adicional | Manual, fácil de esquecer durante incidentes | Triagem rápida e sprints de ajuste de consulta |
| APM completo (Datadog, New Relic) | Correlaciona traces de aplicação com SQL | Custo e outro sistema para operar | Equipes que precisam de correlação app-para-query |
cl_waiting aumentando) enquanto o lado do Postgres ainda mostra muitas conexões livres.Se os usuários estão atualmente esperando no banco de dados e, se sim, qual recurso ou bloqueio está causando essa espera.
As cargas de trabalho do Postgres são frequentemente limitadas por contenção de bloqueio ou I/O de disco, então a CPU pode parecer baixa enquanto as sessões estão efetivamente presas.
Um wait_event não nulo informa imediatamente que um backend está bloqueado em vez de executando ativamente, direcionando a triagem para bloqueios, I/O ou outro backend.
Não, um pooler como o PgBouncer pode mostrar cl_waiting aumentando enquanto a instância do Postgres ainda tem capacidade de backend livre.
O impacto cumulativo reflete melhor o custo real da carga de trabalho, pois uma consulta frequente e barata pode consumir mais tempo agregado do banco de dados do que uma consulta rara e lenta.
Pressão de escrita no primário gerando WAL mais rápido do que o standby ou assinante pode reproduzir, não geralmente um problema de rede bruto.
Não, alertar sobre cada desvio causa fadiga; as políticas de alerta devem ter como alvo os sintomas que os usuários realmente sentem, como exaustão de conexão ou atraso além de um orçamento acordado.
A mesma porcentagem de utilização significa algo diferente em um cluster que normalmente fica ocioso em baixa em comparação com um que normalmente fica aquecido, então as diferenças relativas capturam anomalias reais melhor do que os limites estáticos.
Não realmente, pois o aumento das contagens de tuplas mortas degrada os planos de consulta ao longo do tempo, então o inchaço é frequentemente um indicador principal precoce de um problema de desempenho futuro.
Elas cobrem bem as métricas de host e instância, mas a visibilidade em nível de consulta e de bloqueio geralmente ainda precisa ser adicionada pela equipe de aplicação.
Permite que as equipes correlacionem uma tendência de construção lenta, como inchaço crescente ou crescimento de conexões, com um deploy ou alteração de esquema de semanas atrás.
As equipes se afogam em ruído de muitos alertas de baixo valor ou perdem os poucos sinais que realmente precedem um incidente.
wait_event descrita acima.Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (versão principal estável 18, linha de manutenção 17) e PgBouncer 1.x.
Revisado por Chris St. John·Última atualização: 15 de jul. de 2026