postgres postgresql log

Diversos eventos podem ser do interesse do administrador do banco de dados. Falhas de autenticação podem indicar tentativas de ataques. Conexões perdidas podem indicar problemas na rede ou na aplicação. Execuções muito frequentes do checkpointer podem indicar parâmetros de memória inadequados. Locks de longa duração e deadlocks indicam problemas na lógica da aplicação. Mesmo início e fim do serviço são informações importantes, assim como alterações de parâmetros. Cada um dos possíveis eventos gera uma ou mais mensagens, com níveis diferentes de severidade. E essas mensagens são enviadas e armazenadas para consumo do administrador.

Portanto, se torna necessário ajustar as configurações de logs, tanto para que eles contenham todas as informações que precisaremos, quanto para que não contenham informações demais, que consomem recursos desnecessários.

Algumas das configurações que controlam o destino dos logs:

• log_destination: Destino dos logs, que pode ser stderr (padrão) para enviar os logs para a saída padrão, csvlog para salvar eles em formato CSV, syslog para enviar para o syslog e eventlog para enviar para o log de eventos do Windows.
• logging_collector: Habilita um processo adicional no PostgreSQL que coleta logs enviados para stderr e guarda em arquivos de texto, o que é muito útil já que algumas mensagens não podem ser enviadas para o syslog e aparecem apenas em stderr (como mensagens do loader e de processos externos acionados por archive_command).
• log_directory: Diretório de destino dos logs de texto do logging_collector, como caminho absoluto ou caminho relativo ao dicionário de dados.
• log_filename: Padrão de nome dos arquivos de logs do logging collector e do csvlog, permitindo substituições de % como no strftime.
• …

Algumas das configurações que controlam quando gerar mensagens:

• log_min_messages: Controla o nível de mensagens para logar, com os valores: DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL e PANIC. Cada nível inclui todos os posteriores e o nível padrão é WARNING.
• log_min_error_statement: Controla quais mensagens geram erros, com os valores: DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL e PANIC. Cada nível inclui todos os posteriores e o nível padrão é ERROR.
• log_statement: Loga todos os comandos com all, ou DDL (CREATE, ALTER, DROP) com ddl, ou DML (SELECT, INSERT, UPDATE, DELETE) com dml, ou nenhum comando com none (padrão).
• log_min_duration_statement: Faz comandos de longa duração (maiores que o valor dessa configuração) serem logados. O valor -1 (padrão) desabilita e o valor 0 faz logar todos os comandos. Por exemplo um valor 250ms faz com que comandos com duração maior que esse tempo sejam logados.
• log_transaction_sample_rate: Faz com que uma amostra de transações completas sejam logadas. Por exemplo um valor 0.01 faz com que 1% das transações tenham todos os seus comandos completamente logados.
• log_autovacuum_min_duration: Loga execuções do autovacuum com duração maior que o valor fornecido.
• log_checkpoints: Loga execuções do checkpointer.
• log_connections: Loga novas conexões estabelecidas.
• log_disconnections: Loga conexões terminadas.
• log_duration: Loga as durações de todos os comandos.
• log_lock_waits: Loga esperas por locks com durações maiores que deadlock_timeout.
• log_replication_commands: Loga comandos de replicação.
• log_temp_files: Loga uso de arquivos temporários maiores que o tamanho. Por exemplo, um valor 1MB gera uma mensagem de log quando arquivos temporários maiores que 1MB são usados. O valor 0 faz todo uso de arquivos temporários ser logado e o valor -1 desabilita (padrão).
• …

Algumas das configurações que controlam quais informações logar:

• application_name: Qualquer texto fornecido na conexão para identificar a sessão, como o nome da instância do backend ou do microsserviço atendido.
• log_timezone: Fuso horário para datas e horas colocadas nos logs textuais apenas.
• log_line_prefix: Adiciona um prefixo a toda linha enviada aos logs. Esse prefixo é construído a partir de um formato com substituições de %. Por exemplo, um dos formatos sugeridos pelo pgBadger log_line_prefix = '%t [%p]: db=%d,user=%u,app=%a,client=%h ' contém as seguintes substituições:

  padrão	significado	exemplo
  %t	data e hora sem milissegundos	2020-09-24 12:01:00
  %p	PID do backend do PostgreSQL	1234
  %d	nome do banco de dados	appdb
  %u	nome do usuário	appusr
  %a	nome da aplicação, instância ou microsserviço	microservico_saldo
  %h	IP / hostname do cliente / backend da aplicação	10.1.2.34

  Outros padrões de substituição na tabela.
• …

Também é possível adicionar um identificador da instância/cluster, que fica visível no nome do processo, em logs e sistemas de monitoramento, seguinte forma: cluster_name = 'db_webapp_prod'.

1. Habilite algumas das sugestões de logs do pgBadger: http://pgbadger.darold.net/documentation.html#POSTGRESQL-CONFIGURATION
2. Execute alguns comandos para gerar algum volume de logs
3. Confira os logs gerados, especialmente o resultado do log_line_prefix
4. (opcional) Alimente o pgBadger com os logs gerados e estudar o relatório dele