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