É uma boa ideia salvar a saída do registro do servidor de banco de
dados em algum lugar, em vez de simplesmente descartá-la através de
/dev/null.
Os registros são essenciais para diagnosticar problemas.
O registro do servidor pode conter informações confidenciais e
precisa ser protegido, independentemente de como ou onde seja
armazenado, ou do destino para o qual seja encaminhado.
Por exemplo, algumas instruções de DDL podem
conter senhas em texto simples ou outros detalhes de autenticação.
As instruções registradas no nível ERROR podem
mostrar o código-fonte SQL dos aplicativos e
também podem conter partes de linhas de dados.
O registro de dados, eventos e informações relacionadas é a função
pretendida desta funcionalidade, portanto, não se trata de um
vazamento ou de um bug.
Certifique-se de que os registros do servidor sejam visíveis apenas
para pessoas devidamente autorizadas.
A saída de registros tende a ser volumosa (especialmente em níveis de depuração mais altos), portanto, não se vai querer salvá-los indefinidamente. É necessário rotacionar os arquivos de registro para que novos arquivos de registro sejam iniciados e os antigos removidos após um período razoável de tempo.
Se for simplesmente direcionado o stderr do
postgres para um arquivo, haverá a saída de
registro, mas a única maneira de truncar o arquivo de registro é
parando e reiniciando o servidor.
Isto pode ser aceitável se o PostgreSQL
estiver sendo usado em um ambiente de desenvolvimento, mas poucos
servidores de produção achariam este comportamento aceitável.
Uma abordagem melhor é enviar a saída de erro padrão
(stderr) do servidor para algum tipo de programa
de rotação de registros.
Existe uma funcionalidade integrada de rotação de registros, que se
pode usar definindo o parâmetro de configuração
logging_collector como true
no arquivo postgresql.conf.
Os parâmetros de controle para este programa são descritos em
Onde registrar.
Também pode-se usar esta abordagem para capturar os dados de registro
no formato legível por máquina CSV (valores separados por vírgula).
Como alternativa, pode-se preferir usar um programa de rotação de
registro (log) externo, se já houver
um que esteja sendo usado com outro software de servidor.
Por exemplo, a ferramenta
rotatelogs incluída na distribuição do projeto
Apache pode ser usada com o
PostgreSQL.
Uma maneira de fazer isto é encadear a saída
stderr do servidor para o programa desejado.
Se o servidor for iniciado usando o comando pg_ctl,
então a saída de erros stderr já será
redirecionada para stdout, então só será
necessário introduzir um pipe
(|) para fazer o
encadeamento. Por exemplo:
pg_ctl start | rotatelogs /var/log/pgsql_log 86400
Pode-se combinar estas abordagens configurando
logrotate para coletar os arquivos de
log produzidos pelo coletor de
log interno do
PostgreSQL.
Neste caso, o coletor de log define
os nomes e a localização dos arquivos de
log, enquanto
o logrotate realiza o arquivamento
periódico desses arquivos.
Ao iniciar a rotação do arquivo de log,
o logrotate deverá garantir que a aplicação
irá enviar a saída adicional para o novo arquivo.
Isto é geralmente feito com o script postrotate,
que envia o sinal SIGHUP para a aplicação,
que então reabre o arquivo de log.
No PostgreSQL, pode-se executar o comando
pg_ctl com a opção logrotate.
Quando o servidor recebe este comando, o servidor alterna para um
novo arquivo de log, ou reabre o
arquivo existente, dependendo da configuração do
log
(veja Onde registrar).
Ao usar nomes de arquivos de log
estáticos, o servidor poderá falhar ao reabrir o arquivo de
log, se o limite máximo de arquivos
abertos for atingido, ou ocorrer um estouro da tabela de arquivos.
Neste caso, as mensagens de log serão
enviadas para o arquivo de log antigo,
até que uma rotação dos arquivos de log
seja bem-sucedida.
Se logrotate estiver configurado para
comprimir o arquivo de log e excluí-lo,
o servidor poderá perder as mensagens registradas neste intervalo
de tempo.
Para evitar este problema, pode-se configurar o coletor de
log para atribuir nomes de arquivo
de log dinamicamente, e usar o
script prerotate para ignorar os arquivos de
log abertos.
Outra abordagem no nível de produção para gerenciar a saída de
log é enviá-la para
syslog,
e deixar o syslog lidar com a rotação de
arquivo.
Para fazer isto, deve-se definir o parâmetro de configuração
log_destination como syslog
(para registrar apenas no syslog),
no arquivo postgresql.conf.
Então pode-se enviar o sinal SIGHUP para o
daemon syslog
sempre que se quiser forçá-lo a começar a escrever um novo arquivo de
log.
Se for desejado automatizar a rotação de arquivo de
log, o programa
logrotate poderá ser configurado
para trabalhar com os arquivos de log
do syslog.
Entretanto, em muitos sistemas o syslog
não é muito confiável, particularmente com mensagens grandes de
log; pode truncar ou descartar
mensagens exatamente quando mais se precisa delas.
Além disso, no Linux, o
syslog descarrega cada mensagem no disco,
resultando em baixo desempenho.
(Pode-se usar o “-” no início do
nome do arquivo na configuração de syslog
para desativar a sincronização.)
Note que todas as soluções descritas acima cuidam de iniciar novos arquivos de log em intervalos configuráveis, mas não lidam com a remoção dos arquivos de log antigos e inúteis. Provavelmente se desejará agendar uma tarefa para remover periodicamente os arquivos de log antigos. Outra possibilidade é configurar o programa de rotação para que os arquivos de log antigos sejam sobrescritos ciclicamente.
Recursos externos
O pgBadger é um programa Perl autônomo que faz análises sofisticadas de arquivos de log do PostgreSQL.
O script check_postgres fornece alertas Nagios quando mensagens importantes aparecem nos arquivos de log, bem como a detecção de muitas outras condições extraordinárias.