Обслуживание файла журнала
Эта страница переведена при помощи нейросети GigaChat.
Желательно сохранять журналы сервера баз данных в отдельном месте, а не отправлять их в /dev/null. Журналы играют важную роль при анализе и устранении неисправностей.
Журнал сервера может содержать чувствительную информацию и требует надежной защиты независимо от места и способа хранения. Например, некоторые операторы DDL могут содержать пароли в открытом виде или другие аутентификационные данные. Ошибочные события уровня ERROR способны демонстрировать исходный SQL-код приложений и фрагменты данных. Сбор данных, событий и сопутствующей информации является штатной функцией журнала, а не утечкой или багом. Убедитесь, что доступ к журналу сервера открыт только ответственным сотрудникам.
Лог-файлы обычно получаются весьма объемными, особенно при высоком уровне отладочной информации, поэтому бесконечное хранение журналов нежелательно. Нужно периодически поворачивать файлы журналов, чтобы начинать новые файлы и своевременно удалять старые.
Если просто перенаправить stderr из процесса postgres в файл, получится рабочий журнал, но сократить его можно только остановив и перезапустив сервер. Это допустимо для разработки, но для производственных систем такой подход малопригоден.
Лучшее решение — перенаправить stderr в специализированную программу вращения журналов. Встроенная функция вращательного сбора журналов настраивается с помощью параметра конфигурации logging_collector. Настройки собраны в разделе Где вести журнал. С помощью этого метода можно собирать логи в формате CSV для удобной дальнейшей обработки.
Другой подход — использовать внешнюю программу для поворота журналов, если она уже используется в инфраструктуре с другими серверами. Например, утилита rotatelogs, идущая в комплекте с Apache, вполне подойдет для PostgreSQL. Перенаправить stderr сервера в эту программу можно через конвейер. Если сервер запущен через pg_ctl, stderr уже направлен в stdout, поэтому нужен простой пайплайн, например:
pg_ctl start | rotatelogs /var/log/pgsql_log 86400
Можно комбинировать оба подхода: настроить утилиту logrotate для архивации файлов журнала, создаваемых внутренним механизмом сбора логов PostgreSQL. В этом сценарии сборщик журналов назначает имена и местонахождение файлов, а logrotate периодически архивирует их. При инициации цикла ротации logrotate должна удостовериться, что дальнейшее ведение журнала продолжается в новом файле. Обычно это достигается с помощью скрипта postrotate, отправляющим сигнал SIGHUP приложению, заставляющему его повторно открыть файл журнала. В PostgreSQL вместо этого можно выполнить команду pg_ctl с опцией logrotate. Получив эту команду, сервер либо перейдет на новый файл журнала, либо заново откроет текущий файл, в зависимости от настроек журналирования (см. раздел Где вести журнал).
Если имена файлов журнала постоянны, сервер может не успеть повторно открыть файл журнала при достижении лимита открытых файлов или переполнения таблицы файлов. В результате сообщения будут писаться в старый файл до успешного завершения ротации. Если logrotate настроен на сжатие и последующее удаление журнала, сервер потеряет сообщения, зарегистрированные в этот промежуток времени. Чтобы избежать потери данных, можно настроить сборщик журналов на динамическое назначение имен файлов и использовать скрипт prerotate для пропуска активных файлов журнала.
Еще один профессиональный подход к управлению журналами — направление их в syslog и передача обязанностей по ротации файлов службе syslog. Для этого нужно установить параметр конфигурации log_destination на значение syslog (для отправки журналов только в syslog) в файле postgresql.conf. Затем демон syslog можно попросить начать запись в новый файл журнала, отправив ему сигнал SIGHUP. Если необходимо автоматизировать ротацию, программу logrotate можно настроить на работу с файлами журнала из syslog.
Однако в ряде систем syslog оказывается ненадежной, особенно при большом объеме сообщений журнала: он может обрезать или терять записи в самые важные моменты. Кроме того, в Linux syslog синхронно пишет каждое сообщение на диск, что негативно сказывается на производительности. (Синхронизацию можно отключить, добавив знак минус - перед именем файла в файле конфигурации syslog.)
Заметьте, что предложенные выше решения помогают создавать новые файлы журнала с регулируемой частотой, но не решают задачу удаления старых, уже ненужных файлов. Возможно, стоит настроить пакетную задачу для регулярного удаления старых журналов. Альтернатива — настроить программу ротации так, чтобы старые файлы журналов перезаписывались циклически.
Проект pgBadger выполняет глубокий анализ файлов журналов. Программа check_postgres генерирует предупреждения Nagios при обнаружении значимых сообщений в журналах и выявляет другие аномалии.