Es una buena idea guardar la salida del registro del servidor de la base de datos en algún lugar, en lugar
de simplemente descartarla a través de /dev/null. La salida del registro es invaluable para
diagnosticar problemas.
El registro del servidor puede contener información confidencial y debe protegerse, independientemente de cómo
o dónde se almacene, o del destino al que se dirija. Por ejemplo, algunas sentencias DDL pueden contener contraseñas
en texto plano u otros detalles de autenticación. Las sentencias registradas en el nivel ERROR
pueden mostrar el código fuente SQL de las aplicaciones y también pueden contener algunas partes de las filas de datos.
Registrar datos, eventos e información relacionada es la función prevista de esta utilidad, por lo que esto no es una
filtración o un error. Asegúrate de que los registros del servidor sean visibles únicamente para personas con la
autorización adecuada.
La salida del registro tiende a ser voluminosa (especialmente en los niveles de depuración más altos), por lo que no querrás guardarla indefinidamente. Necesitas rotar los archivos de registro para que se inicien nuevos archivos de registro y se eliminen los antiguos después de un período de tiempo razonable.
Si simplemente diriges el stderr de postgres hacia un archivo, tendrás
la salida del registro, pero la única forma de truncar el archivo de registro es detener y reiniciar el servidor.
Esto podría ser aceptable si utilizas PostgreSQL en un entorno de desarrollo, pero pocos
servidores de producción considerarían aceptable este comportamiento.
Un enfoque mejor es enviar la salida stderr del servidor a algún tipo de programa de rotación
de registros. Hay una utilidad de rotación de registros integrada, que puedes utilizar estableciendo el parámetro de
configuración logging_collector a true en postgresql.conf.
Los parámetros de control para este programa se describen en Section 19.8.1. También
puedes utilizar este enfoque para capturar los datos del registro en formato CSV (valores separados
por comas) legible por máquina.
Alternativamente, es posible que prefieras utilizar un programa de rotación de registros externo si ya estás utilizando
uno con otro software de servidor. Por ejemplo, la herramienta rotatelogs incluida en la
distribución de Apache se puede utilizar con PostgreSQL.
Una forma de hacerlo es redirigir la salida stderr del servidor al programa deseado. Si inicias
el servidor con pg_ctl, entonces stderr ya está redirigido a
stdout, por lo que solo necesitas un comando de tubería (pipe), por ejemplo:
pg_ctl start | rotatelogs /var/log/pgsql_log 86400
Puedes combinar estos enfoques configurando logrotate para recopilar los archivos de registro
producidos por el colector de registros integrado de PostgreSQL. En este caso, el colector de
registros de PostgreSQL define los nombres y la ubicación de los archivos de registro, mientras que
logrotate archiva periódicamente estos archivos. Al iniciar la rotación de registros,
logrotate debe asegurarse de que la aplicación envíe la salida posterior al nuevo archivo.
Esto se hace comúnmente con un script postrotate que envía una señal SIGHUP a la
aplicación, la cual luego vuelve a abrir el archivo de registro. En PostgreSQL, en su lugar,
puedes ejecutar pg_ctl con la opción logrotate. Cuando el servidor recibe este
comando, el servidor cambia a un nuevo archivo de registro o vuelve a abrir el archivo existente, dependiendo de la
configuración del registro (consulta Section 19.8.1).
Cuando se utilizan nombres de archivo de registro estáticos, el servidor podría no volver a abrir el archivo de registro
si se alcanza el límite de archivos abiertos máximos o si se produce un desbordamiento de la tabla de archivos. En este
caso, los mensajes de registro se envían al archivo de registro antiguo hasta que se realice una rotación de registros
con éxito. Si logrotate está configurado para comprimir el archivo de registro y eliminarlo,
el servidor puede perder los mensajes registrados en este intervalo de tiempo. Para evitar este problema, puedes configurar
el colector de registros para asignar dinámicamente nombres de archivos de registro y utilizar un script
prerotate para ignorar los archivos de registro abiertos.
Otro enfoque de nivel de producción para gestionar la salida del registro es enviarla a syslog
y dejar que syslog se encargue de la rotación de archivos. Para hacerlo, establece el parámetro
de configuración log_destination a syslog (para registrar únicamente en
syslog) en postgresql.conf. Luego puedes enviar una señal
SIGHUP al demonio syslog cada vez que desees forzarlo a comenzar a escribir
un nuevo archivo de registro. Si deseas automatizar la rotación de registros, el programa logrotate
se puede configurar para trabajar con los archivos de registro de syslog.
En muchos sistemas, sin embargo, syslog no es muy confiable, particularmente con mensajes de
registro grandes; podría truncar o descartar mensajes justo cuando más los necesitas. Además, en
Linux, syslog vaciará cada mensaje en el disco, lo que da lugar a
un rendimiento deficiente. (Puedes utilizar un “-” al principio del nombre del archivo
en el archivo de configuración de syslog para desactivar la sincronización).
Ten en cuenta que todas las soluciones descritas anteriormente se encargan de iniciar nuevos archivos de registro a intervalos configurables, pero no gestionan la eliminación de los archivos de registro antiguos que ya no son útiles. Probablemente querrás configurar una tarea por lotes para eliminar periódicamente los archivos de registro antiguos. Otra posibilidad es configurar el programa de rotación para que los archivos de registro antiguos se sobrescriban cíclicamente.
pgBadger es un proyecto externo que realiza análisis sofisticados de archivos de registro. check_postgres proporciona alertas de Nagios cuando aparecen mensajes importantes en los archivos de registro, así como la detección de muchas otras condiciones extraordinarias.