Примечание

Журнал сервера может содержать конфиденциальную информацию и должен быть защищен независимо от способа и места его хранения, а также от того, куда направляется его вывод. Например, некоторые SQL-инструкции DDL могут содержать пароли в открытом виде или иные данные аутентификации. Записываемые в журнал инструкции на ERROR уровне могут содержать исходный код SQL-запросов приложений, а также части строк данных. Регистрация данных, событий и сопутствующей информации является целевой функцией данного механизма, поэтому это не считается утечкой данных или ошибкой. Пожалуйста, убедитесь, что журналы сервера доступны только лицам, имеющим соответствующие полномочия.

Объем вывода в журнал может быть весьма значительным (особенно на высоких уровнях отладки), поэтому его не следует хранить бесконечно. Вам необходимо выполнять ротацию файлов журналов, чтобы создавались новые файлы журналов, а старые удалялись по истечении определенного периода времени.

Если вы просто перенаправите поток stderr процесса postgres в файл, вы получите вывод журнала, однако единственным способом очистки файла журнала будет остановка и перезапуск сервера. Это может быть допустимо при использовании Digital Q.DataBase в среде разработки, но для большинства производственных серверов такое поведение неприемлемо.

Более подходящим подходом является передача stderr вывода сервера какой-либо программе ротации журналов. В системе предусмотрен встроенный механизм ротации журналов, который можно задействовать, установив параметр конфигурации logging_collector в значение true в postgresql.conf. Управляющие параметры для данного механизма описаны в Раздел 3.4.8.1. Данный подход также можно использовать для сохранения данных журнала в машиночитаемом CSV формате (значения, разделенные запятыми).

Кроме того, вы можете использовать внешнюю программу ротации журналов, если она уже применяется для другого серверного программного обеспечения. Например, rotatelogs инструмент, входящий в состав Apache дистрибутива, может использоваться с Digital Q.DataBase. Одним из способов реализации этого является перенаправление stderr стандартного вывода сервера в соответствующую программу. Если запуск сервера выполняется с помощью pg_ctl, то stderr уже перенаправлен в stdout, и достаточно использовать команду конвейера, например:

pg_ctl start | rotatelogs /var/log/pgsql_log 86400

Данные подходы можно комбинировать, настроив logrotate для обработки файлов журналов, создаваемых Digital Q.DataBase встроенным сборщиком сообщений журнала. В этом случае сборщик сообщений журнала определяет имена и расположение файлов журналов, тогда как logrotate периодически архивирует эти файлы. При инициировании ротации журналов, logrotate необходимо обеспечить перенаправление последующего вывода приложения в новый файл. Обычно это реализуется при помощи postrotate скрипта, отправляющего SIGHUP сигнал приложению, которое затем повторно открывает файл журнала. В Digital Q.DataBase, можно запустить pg_ctl с параметром logrotate вместо этого. При получении этой команды сервер либо переключается на новый файл журнала, либо повторно открывает существующий файл в зависимости от настроек ведения журнала (см. Раздел 3.4.8.1).

Другим подходом промышленного уровня к управлению выводом журналов является их передача в службу syslog с последующим использованием механизмов syslog для ротации файлов. Для этого установите параметр конфигурации log_destination в значение syslog (для ведения журнала только через syslog ) в файле postgresql.conf. После чего вы сможете отправлять SIGHUP сигнал демону syslog в любой момент, когда требуется принудительно начать запись в новый файл журнала. Для автоматизации ротации журналов logrotate программа может быть настроена для работы с файлами журналов syslog.

Однако во многих системах механизм syslog не отличается высокой надежностью, особенно при передаче объемных сообщений журнала; он может обрезать или отбрасывать сообщения именно тогда, когда они наиболее важны. Кроме того, в Linux, syslog будет выполнять принудительный сброс каждого сообщения на диск, что приведет к низкой производительности. (Для отключения синхронизации можно использовать символ «-» в начале имени файла в syslog конфигурационном файле).

Следует отметить, что все описанные выше решения обеспечивают создание новых файлов журналов через заданные интервалы времени, однако они не предусматривают удаление старых, неактуальных файлов журналов. Рекомендуется настроить пакетное задание для периодического удаления устаревших файлов журналов. Другой вариант заключается в такой настройке программы ротации, при которой старые файлы журналов будут перезаписываться циклически.

pgBadger представляет собой внешний проект для углубленного анализа файлов журналов. check_postgres обеспечивает отправку оповещений в Nagios при появлении в файлах журналов критически важных сообщений, а также позволяет выявлять различные нештатные ситуации.