Logging & Audit Trails Explained
O logging e a auditoria do PostgreSQL parecem um único tópico do lado de fora, mas na verdade são três mecanismos distintos que respondem a três perguntas investigativas distintas.
//
Busque em todas as páginas da documentação
O logging e a auditoria do PostgreSQL parecem um único tópico do lado de fora, mas na verdade são três mecanismos distintos que respondem a três perguntas investigativas distintas.
Esta página constrói o modelo mental que separa esses mecanismos: logs do servidor, auditoria em nível de instrução via pgaudit e histórico em nível de linha via triggers de auditoria, para que você possa escolher a ferramenta certa em vez de usar aquela que já está configurada.
O log do servidor é o gravador de voo de propósito geral do PostgreSQL, capturando conexões, desconexões, erros, checkpoints e, opcionalmente, consultas lentas.
Ele responde a perguntas operacionais como "esta conexão foi bem-sucedida" ou "qual consulta demorou mais que o limite de latência", e existe em todos os clusters por padrão em alguma forma mínima.
pgaudit é uma extensão desenvolvida especificamente que adiciona logging de acesso estruturado em nível de instrução sobre o log do servidor, respondendo "quem executou qual tipo de SQL contra quais objetos".
Triggers de auditoria são um mecanismo completamente diferente: triggers em nível de aplicação que gravam valores de linha antes e depois em tabelas de auditoria dedicadas, respondendo "como essa linha específica estava antes e depois de ser alterada".
A distinção que mais importa é a granularidade: logs do servidor e pgaudit descrevem instruções e conexões, enquanto triggers de auditoria descrevem alterações de dados em nível de linha com valores antigos e novos capturados.
Uma analogia útil é uma loja de varejo: o log do servidor é o balcão de entrada da porta, o pgaudit é a câmera de segurança registrando quem andou por qual corredor, e os triggers de auditoria são o recibo detalhado mostrando exatamente o que mudou de mãos.
Nenhum dos três substitui o outro, porque um recibo não diz nada sobre quem estava navegando sem comprar, e um contador de porta não diz nada sobre o que estava na cesta de alguém.
O PostgreSQL 18.4 tem como padrão um logging mínimo, então quase todas essas capacidades exigem configuração deliberada antes de produzir evidências úteis.
Esses mecanismos ficam em pontos diferentes do ciclo de vida da solicitação, o que explica tanto seus pontos fortes quanto suas lacunas.
O log do servidor é preenchido como um efeito colateral da execução de conexão e consulta, controlado por configurações como log_connections, log_statement e log_min_duration_statement.
O pgaudit se integra ao mesmo caminho de execução, mas classifica a atividade em categorias lógicas (read, write, ddl, role), permitindo que as equipes limitem o logging às classes exatas que um programa de conformidade exige, em vez de um interruptor "tudo ou nada".
Os triggers de auditoria executam dentro da mesma transação da alteração de dados em si, disparando em INSERT, UPDATE ou DELETE e gravando uma linha em uma tabela de auditoria antes que a transação original seja confirmada.
Esse acoplamento transacional é a principal diferença mecânica: o registro de um trigger de auditoria é confirmado com a alteração que ele descreve ou é revertido com ela, enquanto uma linha de log gravada no log do servidor não é transacional nesse mesmo sentido.
-- Um mecanismo concretizado: um trigger de auditoria mínimo captura
-- o estado da linha antigo/novo transacionalmente, vinculado à alteração que ele descreve.
CREATE FUNCTION audit_orders() RETURNS trigger AS $$
BEGIN
INSERT INTO audit.orders_history(order_id, old_row, new_row, changed_at)
VALUES (COALESCE(NEW.id, OLD.id), to_jsonb(OLD), to_jsonb(NEW), now());
RETURN COALESCE(NEW, OLD);
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;O volume é a outra preocupação mecânica que conecta todos os três: registrar cada instrução em um cluster OLTP movimentado pode encher o disco em horas, então tanto os logs do servidor quanto o pgaudit são projetados para serem escopados de forma restrita (apenas consultas lentas, apenas DDL, roles específicos) em vez de serem executados com verbosidade máxima por padrão.
Um erro de raciocínio frequente é tratar o volume de log puramente como um problema de infraestrutura, quando na verdade é um problema de design de evidência: registrar tudo produz tanto ruído que encontrar a única linha relevante durante um incidente se torna sua própria investigação.
Em escala, logging e auditoria se tornam um problema de retenção e pipeline tanto quanto um problema de captura.
Centralizar logs em um SIEM ou pipeline de envio de logs desacopla a retenção do disco local, o que é importante porque os programas de conformidade geralmente exigem de 90 dias a vários anos de evidências retidas que um host de banco de dados nunca foi projetado para armazenar localmente.
Formatos estruturados como csvlog ou a saída de log JSON do PostgreSQL existem especificamente para tornar esse pipeline confiável, já que analisar a saída stderr não estruturada em escala é frágil em comparação com a análise de campos bem definidos.
Dados regulamentados introduzem uma tensão específica: evidências de auditoria devem ser capturadas, mas a mesma evidência (texto da consulta, valores de linha) pode conter os dados sensíveis que estão sendo protegidos, portanto, a redação e o controle de acesso na trilha de auditoria são tão importantes quanto nas tabelas de origem.
Triggers de auditoria e pgaudit são frequentemente combinados em vez de escolhidos exclusivamente, com o pgaudit fornecendo a trilha de acesso ampla exigida por frameworks como PCI DSS e triggers fornecendo histórico em nível de linha para as tabelas específicas onde "qual era o valor antigo" é uma questão regulatória real.
A resistência à adulteração é um detalhe de design que merece atenção deliberada: as tabelas de auditoria geralmente devem revogar UPDATE e DELETE de roles de aplicação para que apenas o próprio trigger possa anexar linhas, preservando o valor probatório da trilha.
| Abordagem | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
Log do servidor (log_min_duration_statement, log_statement) | Infraestrutura extra zero, sempre disponível | Grosso, não consultável como dados estruturados | Solução de problemas operacionais, captura de consultas lentas |
| pgaudit | Trilha de acesso estruturada, classificada e com escopo de role | Sem valores de linha antigos/novos, pipeline de log necessário | Evidência de conformidade em nível de instrução (SOC2, PCI) |
| Triggers de auditoria | Valores antes/depois em nível de linha, consultáveis em SQL | Sobrecarga de escrita, esforço de implementação por tabela | Histórico de linha exigido pelo regulador, UI de alteração no aplicativo |
Logs do servidor registram eventos operacionais, pgaudit adiciona uma trilha de acesso estruturada em nível de instrução, e triggers de auditoria capturam valores de linha antes/depois transacionalmente.
É não estruturado e orientado a eventos, faltando a trilha de acesso classificada e consultável que frameworks como SOC2 ou PCI normalmente exigem.
Não, o pgaudit registra o texto da instrução e a classificação de acesso, não os dados da linha; capturar valores antigos/novos requer um trigger de auditoria gravando em uma tabela de histórico.
A linha de auditoria do trigger é gravada dentro da mesma transação da alteração de dados, então ela é confirmada ou revertida junto com ela, ao contrário de uma linha de log do servidor.
Pode encher o disco em horas em uma carga de trabalho movimentada e enterra as linhas de log genuinamente úteis no ruído durante um incidente.
Frequentemente sim, com pgaudit fornecendo evidências amplas de acesso em várias tabelas e triggers fornecendo histórico em nível de linha nas tabelas específicas onde os valores antigos importam.
Torna o envio de logs para um SIEM ou pipeline confiável, já que analisar campos bem definidos é muito mais robusto do que analisar texto stderr não estruturado.
O texto da consulta e os valores de linha capturados podem conter os mesmos dados sensíveis que a trilha de auditoria existe para proteger, então a trilha precisa de seus próprios controles de acesso.
Revogar UPDATE e DELETE de roles de aplicação para que apenas a função trigger possa anexar novas linhas preserva o valor probatório da trilha.
Geralmente sim, porque as janelas de retenção de conformidade frequentemente excedem o que um host de banco de dados foi projetado para armazenar localmente, e a centralização desacopla a retenção do disco local.
Elas normalmente fornecem infraestrutura de entrega de logs (CloudWatch, Cloud Logging), mas a configuração do logging em si, e qualquer design de trigger de auditoria, permanece responsabilidade do cliente.
Descobrir durante um incidente ou auditoria de conformidade que a evidência específica necessária, seja trilha de acesso ou histórico de linha, nunca estava sendo capturada.
Versões do Stack: Esta página foi escrita para PostgreSQL 18.4 (major estável 18, linha de manutenção 17).
Revisado por Chris St. John·Última atualização: 15 de jul. de 2026