20.8. Регистрация ошибок и протоколирование работы сервера
20.8.1. Куда протоколировать
log_destination(string)PostgreSQL поддерживает несколько методов протоколирования сообщений сервера: stderr, csvlog и syslog. На Windows также поддерживается eventlog. В качестве значения
log_destinationуказывается один или несколько методов протоколирования, разделённых запятыми. По умолчанию используется stderr. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера.Если в
log_destinationвключено значение csvlog, то протоколирование ведётся в формате CSV (разделённые запятыми значения). Это удобно для программной обработки журнала. Подробнее об этом в Подразделе 20.8.4. Для вывода в формате CSV должен быть включён logging_collector.Если присутствует указание stderr или csvlog, создаётся файл
current_logfiles, в который записывается расположение файла(ов) журнала, в настоящее время используемого сборщиком сообщений для соответствующего назначения. Это позволяет легко определить, какие файлы журнала используются в данный момент экземпляром сервера. Например, он может иметь такое содержание:stderr log/postgresql.log csvlog log/postgresql.csv
current_logfilesпереписывается когда при прокрутке создаётся новый файл журнала или когда изменяется значениеlog_destination. Он удаляется, когда вlog_destinationне задаётся ни stderr, ни csvlog, а также когда сборщик сообщений отключён.Примечание
В большинстве систем Unix потребуется изменить конфигурацию системного демона syslog для использования варианта syslog в
log_destination. Для указания типа протоколируемой программы (facility), PostgreSQL может использовать значения сLOCAL0поLOCAL7(см. syslog_facility). Однако на большинстве платформ конфигурация syslog по умолчанию не учитывает сообщения подобного типа. Чтобы это работало, потребуется добавить в конфигурацию демона syslog что-то подобное:local0.* /var/log/postgresql
Для использования
eventlogвlog_destinationна Windows, необходимо зарегистрировать источник событий и его библиотеку в операционной системе. Тогда Windows Event Viewer сможет отображать сообщения журнала событий. Подробнее в Разделе 19.12.logging_collector(boolean)Параметр включает сборщик сообщений (logging collector). Это фоновый процесс, который собирает отправленные в stderr сообщения и перенаправляет их в журнальные файлы. Такой подход зачастую более полезен чем запись в syslog, поскольку некоторые сообщения в syslog могут не попасть. (Типичный пример с сообщениями об ошибках динамического связывания, другой пример — ошибки в скриптах типа
archive_command.) Для установки параметра требуется перезапуск сервера.Примечание
Можно обойтись без сборщика сообщений и просто писать в stderr. Сообщения будут записываться в место, куда направлен поток stderr. Такой способ подойдёт только для небольших объёмов протоколирования, потому что не предоставляет удобных средств для организации ротации журнальных файлов. Кроме того, на некоторых платформах отказ от использования сборщика сообщений может привести к потере или искажению сообщений, так как несколько процессов, одновременно пишущих в один журнальный файл, могут перезаписывать информацию друг друга.
Примечание
Сборщик спроектирован так, чтобы сообщения никогда не терялись. А это значит, что при очень высокой нагрузке, серверные процессы могут быть заблокированы при попытке отправить сообщения во время сбоя фонового процесса сборщика. В противоположность этому, syslog предпочитает удалять сообщения, при невозможности их записать. Поэтому часть сообщений может быть потеряна, но система не будет блокироваться.
log_directory(string)При включённом
logging_collector, определяет каталог, в котором создаются журнальные файлы. Можно задавать как абсолютный путь, так и относительный от каталога данных кластера. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера. Значение по умолчанию —log.log_filename(string)При включённом
logging_collectorзадаёт имена журнальных файлов. Значение трактуется как строка формата в функцииstrftime, поэтому в ней можно использовать спецификаторы%для включения в имена файлов информации о дате и времени. (При наличии зависящих от часового пояса спецификаторов%будет использован пояс, заданный в log_timezone.) Поддерживаемые спецификаторы%похожи на те, что перечислены в описании strftime спецификации Open Group. Обратите внимание, что системная функцияstrftimeнапрямую не используется. Поэтому нестандартные, специфичные для платформы особенности не будут работать. Значение по умолчаниюpostgresql-%Y-%m-%d_%H%M%S.log.Если для задания имени файлов не используются спецификаторы
%, то для избежания переполнения диска, следует использовать утилиты для ротации журнальных файлов. В версиях до 8.4, при отсутствии спецификаторов%, PostgreSQL автоматически добавлял время в формате Epoch к имени файла. Сейчас в этом больше нет необходимости.Если в
log_destinationвключён вывод в формате CSV, то к имени журнального файла будет добавлено расширение.csv. (Еслиlog_filenameзаканчивается на.log, то это расширение заменится на.csv.)Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера.log_file_mode(integer)В системах Unix задаёт права доступа к журнальным файлам, при включённом
logging_collector. (В Windows этот параметр игнорируется.) Значение параметра должно быть числовым, в формате командchmodиumask. (Для восьмеричного формата, требуется задать лидирующий0(ноль).)Права доступа по умолчанию
0600, т. е. только владелец сервера может читать и писать в журнальные файлы. Также, может быть полезным значение0640, разрешающее чтение файлов членам группы. Однако чтобы установить такое значение, нужно каталог для хранения журнальных файлов (log_directory) вынести за пределы каталога данных кластера. В любом случае нежелательно открывать для всех доступ на чтение журнальных файлов, так как они могут содержать конфиденциальные данные.Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера.log_rotation_age(integer)При включённом
logging_collectorэтот параметр определяет максимальное время жизни отдельного журнального файла, по истечении которого создаётся новый файл. Если это значение задаётся без единиц измерения, оно считается заданным в минутах. Значение по умолчанию — 24 часа. При нулевом значении смена файлов по времени не производится. Задать этот параметр можно только вpostgresql.confили в командной строке при запуске сервера.log_rotation_size(integer)При включённом
logging_collectorэтот параметр определяет максимальный размер отдельного журнального файла. При достижении этого размера создаётся новый файл. Если это значение задаётся без единиц измерения, оно считается заданным в килобайтах. Значение по умолчанию — 10 мегабайт. При нулевом значении смена файлов по размеру не производится. Задать этот параметр можно только вpostgresql.confили в командной строке при запуске сервера.log_truncate_on_rotation(boolean)Если параметр
logging_collectorвключён, PostgreSQL будет перезаписывать существующие журнальные файлы, а не дописывать в них. Однако перезапись при переключении на новый файл возможна только в результате ротации по времени, но не при старте сервера или ротации по размеру файла. При выключенном параметре всегда продолжается запись в существующий файл. Например, включение этого параметра в комбинации сlog_filenameравнымpostgresql-%H.log, приведёт к генерации 24-х часовых журнальных файлов, которые циклически перезаписываются. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера.Пример: для хранения журнальных файлов в течение 7 дней, по одному файлу на каждый день с именами вида
server_log.Mon,server_log.Tueи т. д., а также с автоматической перезаписью файлов прошлой недели, нужно установитьlog_filenameвserver_log.%a,log_truncate_on_rotationвonиlog_rotation_ageв1440.Пример: для хранения журнальных файлов в течение 24 часов, по одному файлу на час, с дополнительной возможностью переключения файла при превышения 1ГБ, установите
log_filenameвserver_log.%H%M,log_truncate_on_rotationвon,log_rotation_ageв60иlog_rotation_sizeв1000000. Добавление%Mвlog_filenameпозволит при переключении по размеру указать другое имя файла в пределах одного часа.syslog_facility(enum)При включённом протоколировании в syslog, этот параметр определяет значение «facility». Допустимые значения
LOCAL0,LOCAL1,LOCAL2,LOCAL3,LOCAL4,LOCAL5,LOCAL6,LOCAL7. По умолчанию используетсяLOCAL0. Подробнее в документации на системный демон syslog. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера.syslog_ident(string)При включённом протоколировании в syslog, этот параметр задаёт имя программы, которое будет использоваться в syslog для идентификации сообщений относящихся к PostgreSQL. По умолчанию используется
postgres. Задать этот параметр можно только вpostgresql.confили в командной строке при запуске сервера.syslog_sequence_numbers(boolean)Когда сообщения выводятся в syslog и этот параметр включён (по умолчанию), все сообщения будут предваряться последовательно увеличивающимися номерами (например,
[2]). Это позволяет обойти подавление повторов «--- последнее сообщение повторилось N раз ---», которое по умолчанию осуществляется во многих реализациях syslog. В более современных реализациях syslog подавление повторных сообщений можно настроить (например, в rsyslog есть директива$RepeatedMsgReduction), так что это может излишне. Если же вы действительно хотите, чтобы повторные сообщения подавлялись, вы можете отключить этот параметр.Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера.syslog_split_messages(boolean)Когда активен вывод сообщений в syslog, этот параметр определяет, как будут доставляться сообщения. Если он включён (по умолчанию), сообщения разделяются по строкам, а длинные строки разбиваются на строки не длиннее 1024 байт, что составляет типичное ограничение размера для традиционных реализаций syslog. Когда он отключён, сообщения сервера PostgreSQL передаются службе syslog как есть, и она должна сама корректно воспринять потенциально длинные сообщения.
Если syslog в итоге выводит сообщения в текстовый файл, результат будет тем же и лучше оставить этот параметр включённым, так как многие реализации syslog не способны обрабатывать большие сообщения или их нужно специально настраивать для этого. Но если syslog направляет сообщения в некоторую другую среду, может потребоваться или будет удобнее сохранять логическую целостность сообщений.
Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера.event_source(string)При включённом протоколировании в event log, этот параметр задаёт имя программы, которое будет использоваться в журнале событий для идентификации сообщений относящихся к PostgreSQL. По умолчанию используется
PostgreSQL. Задать этот параметр можно только при запуске сервера.
20.8.2. Когда протоколировать
log_min_messages(enum)Управляет минимальным уровнем сообщений, записываемых в журнал сервера. Допустимые значения
DEBUG5,DEBUG4,DEBUG3,DEBUG2,DEBUG1,INFO,NOTICE,WARNING,ERROR,LOG,FATALиPANIC. Каждый из перечисленных уровней включает все идущие после него. Чем дальше в этом списке уровень сообщения, тем меньше сообщений будет записано в журнал сервера. По умолчанию используетсяWARNING. Обратите внимание, позицияLOGздесь отличается от принятой в client_min_messages. Только суперпользователи могут изменить этот параметр.log_min_error_statement(enum)Управляет тем, какие SQL-операторы, завершившиеся ошибкой, записываются в журнал сервера. SQL-оператор будет записан в журнал, если он завершится ошибкой с указанным уровнем важности или выше. Допустимые значения:
DEBUG5,DEBUG4,DEBUG3,DEBUG2,DEBUG1,INFO,NOTICE,WARNING,ERROR,LOG,FATALиPANIC. По умолчанию используетсяERROR. Это означает, что в журнал сервера будут записаны все операторы, завершившиеся сообщением с уровнем важностиERROR,LOG,FATALиPANIC. Чтобы фактически отключить запись операторов с ошибками, установите для этого параметра значениеPANIC. Изменить этот параметр могут только суперпользователи.log_min_duration_statement(integer)Записывает в журнал продолжительность выполнения всех команд, время работы которых не меньше указанного. Например, при значении
250msв журнал сервера будут записаны все команды, выполняющиеся 250 миллисекунд и дольше. С помощью этого параметра можно выявить неоптимизированные запросы в приложениях. Если значение этого параметра задаётся без единиц измерения, оно считается заданным в миллисекундах. При нулевом значении записывается продолжительность выполнения всех команд. Со значением -1 (по умолчанию) запись полностью отключается. Изменить этот параметр могут только суперпользователи.Этот параметр переопределяет log_min_duration_sample, то есть запросы с длительностью, превышающей заданное значение, всегда фиксируются в журнале, вне зависимости от параметров извлечения выборки.
Для клиентов, использующих расширенный протокол запросов, будет записываться продолжительность фаз: разбор, связывание и выполнение.
Примечание
При использовании совместно с log_statement, текст SQL-операторов будет записываться только один раз (от использования
log_statement) и не будет задублирован в сообщении о длительности выполнения. Если не используется вывод в syslog, то рекомендуется в log_line_prefix включить идентификатор процесса или сеанса. Это позволит связать текст запроса с записью о продолжительности выполнения, которая появится позже.log_min_duration_sample(integer)Позволяет сделать выборку по продолжительности команд, которые выполнялись не менее чем определённое время. При этом в журнал будут вноситься такие же записи, как и при включённом параметре log_min_duration_statement, но не для всех команд, а только для их подмножества, ограничиваемого параметром log_statement_sample_rate. Например, при значении
100msпредварительно для выборки будут отобраны все SQL-операторы, выполняющиеся 100 миллисекунд и дольше. Этот параметр может быть полезен, когда количество запросов слишком велико, чтобы записывать в журнал их все. Если значение этого параметра задаётся без единиц измерения, оно считается заданным в миллисекундах. При нулевом значении для выборки отбираются команды с любой продолжительностью. Со значением -1 (по умолчанию) формирование выборки по продолжительности полностью отключается. Изменить этот параметр могут только суперпользователи.Этот параметр имеет меньший приоритет, чем
log_min_duration_statement, то есть команды с длительностью, превышающейlog_min_duration_statement, будут регистрироваться в журнале всегда, вне зависимости от того, какой будет выборка.Другие замечания, относящиеся к
log_min_duration_statement, применимы так же и к данному параметру.log_statement_sample_rate(floating point)Определяет, какая доля команд с длительностью, достигшей log_min_duration_sample, будет регистрироваться в журнале. Выборка формируется вероятностным образом, например, со значением
0.5можно считать, что шанс попадания каждой отдельной команды в выборку равен один к двум. Значение по умолчанию —1.0, то есть выбираются и регистрируются все команды. Со значением 0 запись команд выборки, в зависимости от их длительности, отключается, так же как и приlog_min_duration_sample, равном-1. Изменить этот параметр могут только суперпользователи.log_transaction_sample_rate(floating point)Задаёт долю транзакций, команды из которых будут записываться в журнал дополнительно (помимо команд, записываемых по другим причинам). Этот параметр действует на все транзакции, независимо от длительности команд. Выборка осуществляется вероятностным образом, например, со значением
0.1можно считать, что каждая транзакция может попасть в журнал с шансом один к десяти. Параметрlog_transaction_sample_rateможет быть полезен для анализа выборки транзакций. Значение по умолчанию —0, то есть команды из дополнительно выбираемых транзакций не записываются. При значении1записываются все команды из всех транзакций. Изменить этот параметр могут только суперпользователи.Примечание
С этим параметром, как и со всеми остальными, управляющими журналированием команд, могут быть связаны значительные издержки.
В Таблице 20.2 поясняются уровни важности сообщений в PostgreSQL. Также в этой таблице показано, как эти уровни транслируются в системные при использовании syslog или eventlog в Windows.
Таблица 20.2. Уровни важности сообщений
| Уровень | Использование | syslog | eventlog |
|---|---|---|---|
DEBUG1 .. DEBUG5 | Более детальная информация для разработчиков. Чем больше номер, тем детальнее. | DEBUG | INFORMATION |
INFO | Неявно запрошенная пользователем информация, например вывод команды VACUUM VERBOSE. | INFO | INFORMATION |
NOTICE | Информация, которая может быть полезной пользователям. Например, уведомления об усечении длинных идентификаторов. | NOTICE | INFORMATION |
WARNING | Предупреждения о возможных проблемах. Например, COMMIT вне транзакционного блока. | NOTICE | WARNING |
ERROR | Сообщает об ошибке, из-за которой прервана текущая команда. | WARNING | ERROR |
LOG | Информация, полезная для администраторов. Например, выполнение контрольных точек. | INFO | INFORMATION |
FATAL | Сообщает об ошибке, из-за которой прерван текущий сеанс. | ERR | ERROR |
PANIC | Сообщает об ошибке, из-за которой прерваны все сеансы. | CRIT | ERROR |
20.8.3. Что протоколировать
Примечание
Выбирая, что будет записываться в протокол, важно учитывать возможные риски безопасности; подробнее об этом говорится в Разделе 25.3.
application_name(string)application_name— это любая строка длиной не болееNAMEDATALENсимволов (64 символа при стандартной сборке). Обычно устанавливается приложением при подключении к серверу. Значение отображается в представленииpg_stat_activityи добавляется в журнал сервера, при использовании формата CSV. Для прочих форматов,application_nameможно добавить в журнал через параметр log_line_prefix. Значениеapplication_nameможет содержать только печатные ASCII символы. Остальные символы будут заменены знаками вопроса (?).debug_print_parse(boolean)debug_print_rewritten(boolean)debug_print_plan(boolean)Эти параметры включают вывод различной отладочной информации. А именно: вывод дерева запроса, дерево запроса после применения правил или плана выполнения запроса, соответственно. Все эти сообщения имеют уровень
LOG. Поэтому, по умолчанию, они записываются в журнал сервера, но не отправляются клиенту. Отправку клиенту можно настроить через client_min_messages и/или log_min_messages. По умолчанию параметры выключены.debug_pretty_print(boolean)Включает выравнивание сообщений, выводимых
debug_print_parse,debug_print_rewrittenилиdebug_print_plan. В результате сообщения легче читать, но они значительно длиннее, чем в формате «compact», который используется при выключенном значении. По умолчанию включён.log_autovacuum_min_duration(integer)Задаёт время выполнения действия автоочистки, при превышении которого информация об этом действии записывается в журнал. При нулевом значении в журнале фиксируются все действия автоочистки. Значение
-1(по умолчанию) отключает журналирование действий автоочистки. Если это значение задаётся без единиц измерения, оно считается заданным в миллисекундах. Например, если задать значение250ms, в журнале будут фиксироваться все операции автоматической очистки и анализа, выполняемые дольше 250 мс. Кроме того, когда этот параметр имеет любое значение, отличное от-1, в журнал будет записываться сообщение в случае пропуска действия автоочистки из-за конфликтующей блокировки или параллельного удаления отношения. Таким образом, включение этого параметра позволяет отслеживать активность автоочистки. Задать этот параметр можно только вpostgresql.confили в командной строке при запуске сервера. Однако его можно переопределить для отдельных таблиц, изменив их параметры хранения.log_checkpoints(boolean)Включает протоколирование выполнения контрольных точек и точек перезапуска сервера. При этом записывается некоторая статистическая информация. Например, число записанных буферов и время, затраченное на их запись. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера. По умолчанию выключен.
log_connections(boolean)Включает протоколирование всех попыток подключения к серверу, в том числе успешного завершения как аутентификации (если она требуется), так и авторизации клиентов. Изменить его можно только в начале сеанса и сделать это могут только суперпользователи. Значение по умолчанию —
off.Примечание
Некоторые программы, например psql, предпринимают две попытки подключения (первая для определения, нужен ли пароль). Поэтому дублирование сообщения «connection received» не обязательно говорит о наличии проблемы.
log_disconnections(boolean)Включает протоколирование завершения сеанса. В журнал выводится примерно та же информация, что и с
log_connections, плюс длительность сеанса. Изменить этот параметр можно только в начале сеанса и сделать это могут только суперпользователи. Значение по умолчанию —off.log_duration(boolean)Записывает продолжительность каждой завершённой команды. По умолчанию выключен. Только суперпользователи могут изменить этот параметр.
Для клиентов, использующих расширенный протокол запросов, будет записываться продолжительность фаз: разбор, связывание и выполнение.
Примечание
Включение параметра
log_durationне равнозначно установке нулевого значения для log_min_duration_statement. Разница в том, что при превышении значенияlog_min_duration_statementв журнал записывается текст запроса, а при включении данного параметра — нет. Таким образом, приlog_duration=onи положительном значенииlog_min_duration_statementв журнал записывается длительность для всех команд, а текст запроса — только для команд с длительностью, превышающей предел. Такое поведение может оказаться полезным при сборе статистики в условиях большой нагрузки.log_error_verbosity(enum)Управляет количеством детальной информации, записываемой в журнал сервера для каждого сообщения. Допустимые значения:
TERSE,DEFAULTиVERBOSE. Каждое последующее значение добавляет больше полей в выводимое сообщение. ДляTERSEиз сообщения об ошибке исключаются поляDETAIL,H