PostgreSQL: observar além das conexões
Publicado em 01 de novembro de 2026
Parte 5 de 8 — série Observabilidade na prática.
Na API de catálogo do cenário hipotético, uma requisição demora enquanto o banco continua aceitando conexões. Uma possibilidade seria uma transação manter um lock necessário a outra sessão. Outra seria a aplicação aguardar uma conexão livre no pool antes de enviar qualquer SQL. São esperas diferentes, e a observabilidade precisa permitir distingui-las.
O que o exporter faz
Um exporter coleta informações do banco e as expõe num formato que o Prometheus consegue ler. Ele costuma executar consultas SQL a visões estatísticas e outras interfaces do PostgreSQL. Seu usuário precisa de privilégios suficientes para ler as métricas configuradas, mas não precisa automaticamente ser superusuário.
A escolha de privilégios depende das consultas habilitadas e da versão do exporter e do banco. Revise a lista de coletores e as permissões documentadas. Use uma conta exclusiva de monitoramento, limite a conectividade por banco e origem e mantenha credenciais fora do repositório e dos parâmetros visíveis em processos ou logs.
Uma role como pg_monitor facilita acesso a estatísticas, mas pode permitir leitura de informações sensíveis. Compare seus privilégios com os coletores necessários; marcar transações como read-only não elimina esse acesso.
Dar CONNECT a bancos específicos também não remove permissões concedidas a PUBLIC. Revise privilégios efetivos e regras de autenticação para demonstrar a restrição pretendida.
Métricas de cluster e de banco
Algumas informações são gerais à instância: conexões, atividade, checkpoints, WAL ou estado de replicação. Outras pertencem a um banco ou objeto: transações, tamanho, vacuum, análise e tamanho de tabelas e índices.
Se um exporter consulta vários bancos, cuide para não duplicar uma métrica de cluster em cada alvo. Uma soma ingênua pode aparentar crescimento multiplicado conforme novos bancos são adicionados. Separe métricas globais e por banco, usando rótulos e agregações coerentes.
Os nomes específicos das métricas vêm do exporter e podem mudar entre versões ou coletores habilitados. Consulte a documentação correspondente, confira o endpoint real e construa consultas sobre séries observadas. Não assuma que uma métrica existe só porque um dashboard comunitário a utiliza.
Conexões, transações e locks
Conexões usadas comparadas ao limite ajudam a reconhecer pressão, levando em conta conexões reservadas e o pool da aplicação. Separe uma sessão apenas idle de uma sessão idle in transaction: esta mantém uma transação aberta e pode prolongar locks ou a retenção de versões de linhas. O número total, sozinho, não informa quanto trabalho está sendo executado.
Taxas de commits e rollbacks mostram comportamento agregado. Deadlocks podem ser raros e um contador acumulado não representa uma taxa instantânea; use uma janela temporal apropriada. Dependendo do coletor e da consulta, a ausência de sessões aguardando lock pode aparecer como zero ou como ausência de série. Confirme esse contrato antes de interpretar um painel vazio como um estado saudável.
Picos curtos e médias longas contam histórias diferentes. Explore a série numa janela menor antes de concluir que o banco esteve continuamente pressionado.
Vacuum, tamanho e estatísticas de consulta
O autovacuum recupera espaço para reutilização e ajuda a prevenir o esgotamento dos identificadores de transação; o autoanalyze atualiza estatísticas usadas pelo planejador de consultas. Horários da última execução, tuplas estimadas e tamanho de objetos dão pistas, mas não medem necessariamente o custo de uma consulta ou o bloat físico de forma precisa. Trate estimativas como estimativas e confirme com ferramentas adequadas antes de reorganizar tabelas.
pg_stat_statements agrupa execuções por banco, usuário, identificador da consulta (queryid) e indicação de execução no nível superior (toplevel). Isso permite comparar frequência, tempo e I/O de grupos de consultas. O identificador não deve ser tratado como uma identidade permanente entre versões e ambientes.
Exportar identificadores e agregados pode responder perguntas de tendência sem copiar o SQL para o backend. Isso não impede que a conta de monitoramento tenha acesso ao texto na origem. Revise separadamente o que o exporter publica e o que sua credencial permite ler. Se o texto for necessário para uma investigação, defina controles, retenção e acesso explicitamente.
Também verifique a cardinalidade. Identificadores ilimitados ou texto de consulta em labels podem criar muitas séries e divulgar informações. Limite quantas entradas são coletadas e evite valores livres em dimensões que chegam ao Prometheus.
WAL, backups e limites do painel
Tamanho e atividade de WAL, checkpoints e estado de replicação ajudam a observar o fluxo de dados. Estar conectado a um destino de backup ou receber WAL não prova que seja possível restaurar a base. Recuperabilidade requer testes de restauração, consistência e procedimento conhecido, fora do que uma métrica de disponibilidade consegue demonstrar.
Da mesma forma, dead tuples não são uma medida direta de bloat; uma série vazia não quer dizer que o banco falhou; uma query lenta não aponta a causa sem contexto. Painéis devem explicar o escopo e os limites das métricas. Use alertas para condições que pedem ação, e não para cada desvio sem consequência.
Um roteiro de validação
Comece com um alvo de teste. Confira conectividade, permissões, métricas do cluster e dados de um banco permitido. Confirme que uma origem não autorizada é rejeitada. Depois, valide consultas e unidades com períodos curtos e longos. Compare os dados do painel a uma consulta direta de leitura no PostgreSQL, sem imprimir conteúdo sensível.
Ao adicionar um novo coletor, repita a revisão de privilégios, cardinalidade e efeito sobre a carga do banco. A coleta também consome conexões e executa consultas; use intervalos e timeouts compatíveis com o ambiente. No catálogo, primeiro é preciso saber se a espera ocorre antes de enviar o SQL ou durante sua execução no banco. A espera por uma conexão no pool exige métricas do pool ou instrumentação da aplicação; o exporter do PostgreSQL, sozinho, não a observa. Com essa distinção, métricas de conexões, locks e manutenção ajudam a escolher uma intervenção.
Na série: anterior — Host e containers: recursos não contam toda a história; próxima — Serviços: combinar métricas internas e sondagens.