Отчетность и ведение журнала ошибок
Эта страница переведена при помощи нейросети GigaChat.
Где вести журнал
log_destination (string)
PostgreSQL поддерживает несколько методов ведения журнала сообщений сервера, включая stderr, csvlog, jsonlog и syslog. В Windows также поддерживается eventlog. Установите этот параметр для списка желаемых мест назначения журнала, разделенных запятыми. По умолчанию ведется запись только в stderr. Этот параметр можно установить только в файле postgresql.conf или в командной строке сервера.
Если csvlog включен в log_destination, записи журнала выводятся в формате «значения, разделенные запятыми» (CSV), что удобно для загрузки журналов в программы. Для генерации вывода журнала в формате CSV необходимо включить logging_collector.
Если jsonlog включен в log_destination, записи журнала выводятся в JSON формате, что удобно для загрузки журналов в программы. См. раздел Использование вывода журнала в формате JSON для получения подробной информации. Для генерации вывода журнала в формате JSON необходимо включить logging_collector.
Когда включены либо stderr, либо csvlog, либо jsonlog, создается файл current_logfiles, чтобы записать местоположение текущего файла журнала (или файлов), используемого сборщиком журналов и связанного с ним назначения регистрации. Это обеспечивает удобный способ найти журналы, которые в данный момент используются экземпляром. Вот пример содержимого этого файла:
stderr log/postgresql.log
csvlog log/postgresql.csv
jsonlog log/postgresql.json
current_logfiles воссоздается при создании нового файла журнала в результате ротации и при перезагрузке log_destination. Он удаляется, когда ни один из stderr, csvlog или jsonlog не включен в log_destination, а также когда отключен сборщик журналов.
В большинстве систем Unix потребуется изменить конфигурацию демона syslog системы, чтобы использовать опцию syslog для log_destination. PostgreSQL может регистрировать сообщения в syslog с помощью средств от LOCAL0 до LOCAL7 (см. syslog_facility), но стандартная конфигурация syslog на большинстве платформ будет отбрасывать все такие сообщения. Необходимо добавить что-то вроде этого:
local0.* /var/log/postgresql
в файл конфигурации демона syslog, чтобы он заработал.
В Windows при использовании параметра eventlog для log_destination следует зарегистрировать источник событий и его библиотеку в операционной системе, чтобы средство просмотра событий Windows могло отображать сообщения журнала событий корректно. См. раздел Создание кластера баз данных для получения подробной информации.
logging_collector (boolean)
Этот параметр активирует сборщик журналов, который является фоном процессом, захватывающим сообщения журнала, отправленные на stderr и перенаправляющие их в файлы журнала. Этот подход часто более полезен, чем ведение журнала в syslog, поскольку некоторые типы сообщений могут не появляться в выводе syslog. (Один распространенный пример - сообщения об отказе динамического компоновщика; другой - сообщения об ошибках, создаваемые сценариями, такими как archive_command). Этот параметр может быть установлен только при запуске сервера.
Можно вести журнал в stderr без использования сборщика журналов; сообщения журнала просто будут направлены туда, куда направлен stderr сервера. Однако этот метод подходит только для небольшого объема журналов, так как он не предоставляет удобного способа ротации файлов журнала. Кроме того, на некоторых платформах неиспользование сборщика журналов может привести к потере или искажению вывода журнала, потому что несколько процессов, записывающих одновременно в один и тот же файл журнала, могут перезаписывать выходные данные друг друга.
Сборщик журналов разработан таким образом, чтобы никогда не терять сообщения. Это означает, что при чрезвычайно высокой нагрузке серверные процессы могут быть заблокированы при попытке отправки дополнительных сообщений журнала, когда сборщик отстает. В отличие от этого, syslog предпочитает сбрасывать сообщения, если он не может их записать, что означает, что в таких случаях он может не регистрировать некоторые сообщения, но он не будет блокировать остальную часть системы.
log_directory (string)
Когда logging_collector включен, этот параметр определяет каталог, в котором будут созданы файлы журнала. Он может быть указан как абсолютный путь или относительно каталога кластерных данных. Этот параметр можно задать только в файле postgresql.conf или в командной строке сервера. Значение по умолчанию - log.
log_filename (string)
Когда logging_collector включен, этот параметр задает имена файлов создаваемых файлов журнала. Значение рассматривается как шаблон strftime, поэтому для указания изменяющихся во времени имен файлов можно использовать %-экранирование. (Обратите внимание, что если есть какие-либо зависящие от часового пояса экранирования %-, вычисление выполняется в зоне, указанной параметром log_timezone.) Поддерживаемые экранирования % аналогичны перечисленным в спецификации strftime группы Open. Обратите внимание, что система strftime используется не напрямую, так что расширения, специфичные для платформы (нестандартные), не работают. Значение по умолчанию - postgresql-%Y-%m-%d_%H%M%S.log.
Если указано имя файла без экранирования, следует запланировать использование утилиты ротации журнала, чтобы избежать заполнения всего диска. В выпусках до 8.4, если не было экранированных символов, PostgreSQL добавлял эпоху времени создания нового файла журнала, но теперь это уже не так.
Если вывод в формате CSV включен в log_destination, к имени файла с отметкой времени будет добавлено .csv, чтобы создать имя файла для вывода в формате CSV. (Если log_filename заканчивается на .log, вместо этого заменяется суффикс.)
Если вывод в формате JSON включен в log_destination, к имени файла с отметкой времени будет добавлен .json, чтобы создать имя файла для вывода в формате JSON. (Если log_filename заканчивается на .log, вместо этого заменяется суффикс.)
Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.
log_file_mode (integer)
В системах Unix этот параметр устанавливает разрешения для файлов журнала при включении logging_collector . (В Microsoft 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 приведет к созданию двадцати четырех часовых файлов журнала и затем циклической их перезаписи. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.
Пример: Чтобы сохранить журналы за 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, этот параметр определяет syslog «объект», который будет использоваться. Можно выбрать из LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7; значение по умолчанию --- LOCAL0. См. также документацию демона syslog системы. Этот параметр можно задать только в файле postgresql.conf или в командной строке сервера.
syslog_ident (string)
Когда включено ведение журнала в syslog, этот параметр определяет имя программы, используемое для идентификации сообщений PostgreSQL в журналах syslog. Значение по умолчанию --- postgres. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.
syslog_sequence_numbers (boolean)
Когда включен журнал syslog и это включено (по умолчанию), то каждое сообщение будет иметь префикс с увеличивающимся порядковым номером (например, [2]). Это устраняет подавление сообщения «--- последнее сообщение повторяется N раз ---», которое многие реализации syslog выполняют по умолчанию. В более современных реализациях syslog подавление повторяющихся сообщений можно настроить (например, $RepeatedMsgReduction в rsyslog), поэтому это может не понадобиться. Кроме того, можно отключить это, если действительно требуется подавить повторяющиеся сообщения.
Этот параметр может быть задан только в файле postgresql.conf или в командной строке сервера.
syslog_split_messages (boolean)
Когда включено ведение журнала в syslog, этот параметр определяет, как сообщения доставляются в syslog. Когда включено (по умолчанию), сообщения разделяются по строкам, а длинные строки разбиваются так, чтобы они помещались в 1024 байта, что является типичным ограничением размера для традиционных реализаций syslog. При отключении сообщения журнала сервера PostgreSQL передаются службе syslog без изменений, и служба syslog должна справляться с потенциально громоздкими сообщениями.
Если syslog в конечном итоге ведет журнал в текстовый файл, то эффект будет таким же в любом случае, и лучше оставить настройку включенной, поскольку большинство реализаций syslog либо не могут обрабатывать большие сообщения, либо должны быть специально настроены для их обработки. Но если syslog в конечном счете записывает данные в какую-то другую среду, может потребоваться или будет более полезно сохранять логические сообщения вместе.
Этот параметр можно задать только в файле postgresql.conf или в командной строке сервера.
event_source (string)
Когда включен режим ведения журнала в журнал событий, этот параметр определяет имя программы, используемое для идентификации сообщений PostgreSQL в журнале. По умолчанию используется PostgreSQL. Этот параметр можно установить только в файле postgresql.conf или в командной строке сервера.
Когда вести журнал
log_min_messages (enum)
Контролирует, какие уровни сообщений записываются в журнал сервера. Допустимые значения - это DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, и PANIC. Каждый уровень включает все уровни, которые следуют за ним. Чем позже уровень, тем меньше сообщений отправляется в журнал. По умолчанию используется WARNING. Обратите внимание, что LOG имеет здесь другой ранг, чем в client_min_messages. Только суперпользователи и пользователи с соответствующим привилегией SET могут изменить этот параметр.
log_min_error_statement (enum)
Контролирует, какие операторы SQL, вызывающие условие ошибки, записываются в журнал сервера. Текущий оператор SQL включен в запись журнала для любого сообщения указанной серьезности или выше. Допустимые значения - DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, и PANIC. По умолчанию используется значение ERROR, что означает, что будут регистрироваться операторы, вызывающие ошибки, сообщения журнала, фатальные ошибки или паники. Чтобы эффективно отключить регистрацию неудачных операторов, установите этот параметр на PANIC. Только суперпользователи и пользователи с соответствующим привилегией SET могут изменить эту настройку.
log_min_duration_statement (integer)
Вызывает запись длительности каждого завершенного оператора в журнал, если оператор выполнялся не менее указанного времени. Например, если установить его на 250ms, то все операторы SQL, которые выполняются 250 мс или дольше, будут зарегистрированы. Включение этого параметра может помочь в поиске неоптимизированных запросов в приложениях. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Установка этого значения на ноль выводит длительность всех операторов. Значение -1 (по умолчанию) отключает регистрацию продолжительности выполнения операторов. Только суперпользователи и пользователи с соответствующей привилегией SET могут изменить эту настройку.
Это переопределяет log_min_duration_sample, что означает, что запросы с продолжительностью, превышающей это значение, не подлежат выборке и всегда регистрируются.
Для клиентов, использующих расширенный протокол запросов, продолжительность этапов анализа, привязки и выполнения регистрируется независимо.
При использовании этого параметра вместе с log_statement текст операторов, которые регистрируются из-за log_statement , не будет повторяться в сообщении регистрационного журнала продолжительности. Если не используется syslog, рекомендуется регистрировать PID или идентификатор сеанса с помощью log_line_prefix, чтобы можно было связать сообщение оператора с последующим сообщением о продолжительности, используя идентификатор процесса или идентификатор сеанса.
log_min_duration_sample (integer)
Позволяет выборку длительности завершенных операторов, которые выполнялись не менее указанного времени. Это дает тот же тип записей журнала, что и log_min_duration_statement, но только для подмножества выполненных операторов, с частотой выборки, контролируемой log_statement_sample_rate. Если установить его на 100ms , то все операторы SQL, работающие 100 мс или дольше, будут рассматриваться для выборки. Включение этого параметра может быть полезным, когда трафик слишком высок, чтобы регистрировать все запросы. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Установка этого значения на ноль приводит к выборке всех продолжительностей операторов. -1 (по умолчанию) отключает выборку продолжительности операторов. Только суперпользователи и пользователи с соответствующим привилегией SET могут изменить этот параметр.
Этот параметр имеет более низкий приоритет, чем 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, что означает регистрацию всех выборочных операторов. Установка этого значения равным нулю отключает регистрацию продолжительности выборочного оператора, то же самое, что и установка log_min_duration_sample на -1. Только суперпользователи и пользователи с соответствующим привилегией SET могут изменить этот параметр.
log_transaction_sample_rate (floating point)
Устанавливает долю транзакций, все операторы которых регистрируются дополнительно к операторам, зарегистрированным по другим причинам. Это относится к каждой новой транзакции независимо от продолжительности ее операторов. Выборка является стохастической, например 0.1 означает, что статистически существует один шанс из десяти, что любая данная транзакция будет зарегистрирована. log_transaction_sample_rate может быть полезен для создания выборки транзакций. По умолчанию используется значение 0, что означает отсутствие регистрации операторов из каких-либо дополнительных транзакций. Установка этого значения на 1 регистрирует все операторы всех транзакций. Только суперпользователи и пользователи с соответствующей привилегией SET могут изменить этот параметр.
Как и все параметры ведения журнала команд, этот параметр может значительно увеличить нагрузку.
log_startup_progress_interval (integer)
Устанавливает время после которого процесс запуска зарегистрирует сообщение о длительной операции, которая еще не завершена, а также интервал между дальнейшими сообщениями о ходе выполнения этой операции. По умолчанию это 10 секунд. Установка значения 0 отключит эту функцию. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Эта настройка применяется отдельно к каждой операции. Этот параметр можно задать только в файле postgresql.conf или в командной строке сервера.
Например, если синхронизация каталога данных занимает 25 секунд, а затем сброс незарегистрированных отношений занимает 8 секунд, и если для этого параметра установлено значение по умолчанию 10 секунд, то сообщения будут регистрироваться при синхронизации каталога данных после того, как она будет выполняться в течение 10 секунд и снова после того, как она будет выполняться в течение 20 секунд, но ничего не будет зарегистрировано для сброса незарегистрированных отношений.
Таблица ниже объясняет уровни серьезности сообщений, используемые PostgreSQL. Если выходные данные журнала отправляются в syslog или журнал событий Windows eventlog, уровни серьезности преобразуются так, как показано в таблице.
Уровни серьезности сообщений:
| Серьезность | Использование | 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 |
Что регистрировать
То, что решено регистрировать, может иметь последствия для безопасности; см. Раздел Обслуживание файлов журнала.
application_name (string)
application_name может быть любой строкой длиной менее NAMEDATALEN символов (64 символа в стандартной сборке). Обычно оно устанавливается приложением при подключении к серверу. Имя будет отображаться в представлении pg_stat_activity и включено в записи журнала CSV. Он также может быть включен в обычные записи журнала через параметр log_line_prefix. В значении application_name могут использоваться только печатные символы ASCII. Другие символы будут заменены шестнадцатеричными спецсимволами в стиле C.
debug_print_parse (boolean)debug_print_rewritten (boolean)debug_print_plan (boolean)
Эти параметры позволяют выводить различные отладочные данные. Когда они установлены, они выводят результирующее дерево синтаксического анализа, результат переписывания запроса или план выполнения для каждого выполненного запроса. Эти сообщения отправляются на уровне сообщений LOG, поэтому по умолчанию они будут появляться в журнале сервера, но не будут отправлены клиенту. Можно изменить это, настроив client_min_messages и/или log_min_messages. Эти параметры по умолчанию отключены.
debug_pretty_print (boolean)
Когда установлено, debug_pretty_print сдвигает сообщения, создаваемые debug_print_parse, debug_print_rewritten или debug_print_plan. Это приводит к более удобочитаемому, но гораздо более длинному выводу, чем формат «компактный», используемый, когда он выключен. По умолчанию он включен.
log_autovacuum_min_duration (integer)
Приводит к тому, что каждое действие, выполняемое автоподстройкой, регистрируется, если оно выполняется не менее указанного времени. Установка этого значения равным нулю регистрирует все действия автоподстройки. -1 отключает регистрацию действий автоподстройки. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Например, если установить его на 250ms, то все автоматические уборки и анализы, которые выполняются 250 мс или дольше, будут зарегистрированы. Кроме того, когда этот параметр установлен на любое значение, отличное от -1, будет зарегистрировано сообщение, если действие автоподстройки будет пропущено из-за конфликтующей блокировки или одновременно удаленной связи. Значение по умолчанию равно 10min. Включение этого параметра может помочь отслеживать активность автоподстройки. Этот параметр можно установить только в файле postgresql.conf или в командной строке сервера; однако настройка может быть переопределена для отдельных таблиц путем изменения параметров хранения таблицы.
log_checkpoints (boolean)
Приводит к регистрации контрольных точек и точек перезапуска в журнале сервера. Некоторые статистические данные включены в сообщения журнала, включая количество записанных буферов и время, затраченное на их запись. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера. По умолчанию включено.
log_connections (boolean)
Приводит к тому, что каждая попытка подключения к серверу регистрируется, а также успешное завершение аутентификации клиента (при необходимости) и авторизации. Только суперпользователи и пользователи с соответствующим привилегией SET могут изменить этот параметр при запуске сеанса, и он не может быть изменен вообще во время сеанса. По умолчанию установлено значение off.
Некоторые клиентские программы, такие как psql, пытаются подключиться дважды при определении того, требуется ли пароль, поэтому повторяющиеся сообщения «получено подключение» не обязательно указывают на проблему.
log_disconnections (boolean)
Причины завершения сеанса регистрируются. Выход журнала предоставляет информацию, аналогичную log_connections, плюс продолжительность сеанса. Только суперпользователи и пользователи с соответствующим привилегией SET могут изменить этот параметр при запуске сеанса, и его нельзя изменить вообще в рамках сеанса. По умолчанию используется значение off.
log_duration (boolean)
Вызывает регистрацию продолжительности каждого завершенного оператора. По умолчанию используется значение off. Только суперпользователи и пользователи с соответствующей привилегией SET могут изменять эту настройку.
Для клиентов, использующих расширенный протокол запросов, продолжительность этапов анализа, привязки и выполнения регистрируется независимо.
Разница между включением 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, HINT, QUERY и CONTEXT. Вывод VERBOSE включает код ошибки SQLSTATE (см. также Приложение A), имя файла исходного кода, имя функции и номер строки, которые вызвали ошибку. Только суперпользователи и пользователи с соответствующим привилегией SET могут изменить эту настройку.
log_hostname (boolean)
По умолчанию сообщения журнала подключения показывают только IP-адрес подключающегося хоста. Включение этого параметра приводит к регистрации имени хоста. Обратите внимание, что в зависимости от настройки разрешения имен хостов это может привести к значительному снижению производительности. Этот параметр можно установить только в файле postgresql.conf или в командной строке сервера.
log_line_prefix (string)
Это строка в стиле printf, которая выводится в начале каждой строки журнала. Символы % начинают «экранирующие последовательности», которые заменяются информацией о состоянии, как описано ниже. Неизвестные экранирования игнорируются. Другие символы копируются прямо в строку журнала. Некоторые экранированные последовательности распознаются только процессами сеанса и будут рассматриваться фоном процессов, таких как основной серверный процесс, как пустые. Информация о состоянии может быть выровнена либо слева, либо справа путем указания числовой литералы после% и перед опцией. Отрицательное значение приведет к тому, что информация о состоянии будет заполняться пробелами с правой стороны для обеспечения минимальной ширины, тогда как положительное значение будет заполнять слева. Заполнение может быть полезно для облегчения читаемости человеком в файлах журнала.
Этот параметр можно установить только в файле postgresql.conf или в командной строке сервера. По умолчанию используется '%m [%p] ', который регистрирует отметку времени и идентификатор процесса.
| Эскейп | Эффект | Только сессия |
|---|---|---|
%a | Имя приложения | да |
%u | Имя пользователя | да |
%d | Имя базы данных | да |
%r | Удаленное имя хоста или IP-адрес и удаленный порт | да |
%h | Имя удаленного хоста или IP-адрес | да |
%b | Тип бэкенда | нет |
%p | Идентификатор процесса | нет |
%P | Идентификатор процесса лидера параллельной группы, если этот процесс является рабочим процессом параллельного запроса | нет |
%t | Метка времени без миллисекунд | нет |
%m | Метка времени с миллисекундами | нет |
%n | Метка времени с миллисекундами (как эпоха Unix) | нет |
%i | Тег команды: тип текущей команды сеанса | да |
%e | Код ошибки SQLSTATE | нет |
%c | Идентификатор сеанса: см. ниже | нет |
%l | Номер строки журнала для каждого сеанса или процесса, начиная с 1 | нет |
%s | Метка времени начала процесса | нет |
%v | Виртуальный идентификатор транзакции (procNumber/localXID) | нет |
%x | Идентификатор транзакции (0, если не назначен) | нет |
%q | Не производит вывода, но сообщает процессам вне сеанса о необходимости остановиться в этой точке строки; игнорируется процессами сеанса | нет |
%Q | Идентификатор запроса текущего запроса. Идентификаторы запросов не вычисляются по умолчанию, поэтому это поле будет равно нулю, если параметр compute_query_id не включен или не настроен модуль стороннего производителя, который вычисляет идентификаторы запросов. | да |
%% | Буквально % | нет |
Тип бэкенда соответствует столбцу backend_type в представлении pg_stat_activity, но дополнительные типы могут появиться в журнале, которые не отображаются в этом представлении.
%c побег печатает квази-уникальный идентификатор сеанса, состоящий из двух четырехбайтовых шестнадцатеричных чисел (без ведущих нулей), разделенных точкой. Эти числа представляют время запуска процесса и идентификатор процесса, поэтому %c также может использоваться как способ экономии места для печати этих элементов. Например, чтобы сгенерировать идентификатор сеанса из pg_stat_activity, используйте этот запрос:
SELECT to_hex(trunc(EXTRACT(EPOCH FROM backend_start))::integer) || '.' ||
to_hex(pid)
FROM pg_stat_activity;
Если установить непустое значение для log_line_prefix, то следует сделать его последним символом – пробел, чтобы обеспечить визуальное разделение от остальной части строки журнала. Можно также использовать знак препинания.
syslog генерирует собственную временную метку и информацию об идентификаторе процесса, поэтому, вероятно, не нужно включать эти исключения, если ведется журнал в syslog.
Экранирование %q полезно при включении информации, доступной только в контексте сеанса (бэкенда), например имени пользователя или базы данных. Например:
log_line_prefix = '%m [%p] %q%u@%d/%a '
Экранирование %Q всегда сообщает нулевой идентификатор для строк, выводимых с помощью log_statement, поскольку log_statement генерирует вывод до того, как может быть рассчитан идентификатор, включая недопустимые операторы, для которых не может быть рассчитан идентификатор.
log_lock_waits (boolean)
Управляет тем, создается ли сообщение журнала, когда сеанс ожидает дольше, чем deadlock_timeout, чтобы получить блокировку. Это полезно для определения того, вызывают ли ожидания блокировки низкую производительность. По умолчанию это значение равно off. Только суперпользователи и пользователи с соответствующим привилегией SET могут изменить этот параметр.
log_recovery_conflict_waits (boolean)
Управляет созданием сообщения журнала при ожидании процесса запуска дольше, чем deadlock_timeout для конфликтов восстановления. Это полезно для определения того, предотвращают ли конфликты восстановления применение WAL восстановлением.
По умолчанию установлено значение off. Этот параметр можно задать только в файле postgresql.conf или в командной строке сервера.
log_parameter_max_length (integer)
Если больше нуля, каждое значение параметра привязки, регистрируемое сообщением регистрации оператора, не являющимся ошибкой, обрезается до этого количества байт. Ноль отключает регистрацию параметров привязки для журналов операторов, не являющихся ошибками. -1 (по умолчанию) позволяет регистрировать параметры привязки полностью. Если это значение указано без единиц измерения, оно принимается за байты. Только суперпользователи и пользователи с соответствующей привилегией SET могут изменить этот параметр.
Этот параметр влияет только на сообщения журнала, которые выводятся в результате log_statement, log_duration и связанных с ними настроек. Ненулевые значения этого параметра добавляют некоторую нагрузку, особенно если параметры передаются в двоичной форме, поскольку тогда требуется преобразование в текст.
log_parameter_max_length_on_error (integer)
Если значение больше нуля, каждое значение параметра привязки, указанное в сообщениях об ошибках, обрезается до указанного количества байт. Ноль (по умолчанию) отключает включение параметров привязки в сообщения об ошибках. -1 позволяет печатать параметры привязки полностью. Если это значение указано без единиц измерения, оно принимается за байты.
Ненулевые значения этого параметра увеличивают нагрузку, так как PostgreSQL будет вынужден хранить текстовые представления значений параметров в памяти в начале каждого оператора, независимо от того, произойдет ли ошибка в конечном итоге. Нагрузка выше, когда параметры привязки передаются в двоичном виде, чем когда они отправляются в виде текста, поскольку первый случай требует преобразования данных, а второй требует только копирования строки.
log_statement (enum)
Управляет тем, какие операторы SQL регистрируются. Допустимые значения: none (выключено), ddl, mod и all (все операторы). ddl регистрирует все операторы определения данных, такие как CREATE, ALTER и DROP операторы. mod регистрирует все ddl операторы, а также операторы изменения данных, такие как INSERT, UPDATE, DELETE, TRUNCATE и COPY FROM. Операторы PREPARE, EXECUTE и EXPLAIN ANALYZE также регистрируются, если содержащаяся в них команда имеет соответствующий тип. Для клиентов, использующих расширенный протокол запросов, регистрация происходит при получении сообщения Execute, и включаются значения параметров привязки (с удвоенными встроенными одинарными кавычками).
По умолчанию используется none. Только суперпользователи и пользователи с соответствующим привилегией SET могут изменить этот параметр.
Операторы, содержащие простые синтаксические ошибки, не регистрируются даже при установке log_statement = all, поскольку сообщение журнала генерируется только после выполнения базовой разбора для определения типа оператора. В случае расширенного протокола запросов эта настройка также не регистрирует операторы, которые терпят неудачу до фазы выполнения (т.е. во время анализа или планирования разбора). Установите log_min_error_statement на ERROR (или ниже), чтобы регистрировать такие операторы.
Зарегистрированные операторы могут раскрывать конфиденциальные данные и даже содержать пароли в виде обычного текста.
log_replication_commands (boolean)
Включает запись в журнал сервера всех команд репликации и всех случаев получения/освобождения слота репликации процессом walsender. См. раздел Протокол потоковой репликации для получения дополнительной информации о команде репликации. Значение по умолчанию равно . Только суперпользователи и пользователи с соответствующим привилегией могут изменить этот параметр.
log_temp_files (integer)
Управляет регистрацией в журнале имен и размеров временных файлов. Временные файлы могут использоваться для сортировки, хеширования и временного хранения результатов запросов. Когда этот параметр включен, при удалении временного файла информация о нем может записываться в журнал с указанием размера файла в байтах. Значение нуля регистрирует всю информацию о временном файле, а положительные значения регистрируют только те файлы, размер которых больше или равен указанному количеству данных. Если это значение указано без единиц измерения, оно принимается за килобайты. По умолчанию установлено значение -1, которое отключает такую регистрацию. Только суперпользователи и пользователи с соответствующим привилегией SET могут изменить эту настройку.
log_timezone (string)
Устанавливает часовой пояс, используемый для отметок времени, записываемых в журнале сервера. В отличие от TimeZone, это значение является кластерным, поэтому все сеансы будут последовательно сообщать отметки времени. Встроенное значение по умолчанию - GMT, но обычно оно переопределяется в postgresql.conf; initdb установит там значение, соответствующее его системной среде. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.
Использование вывода журнала в формате CSV
Включение csvlog в список log_destination предоставляет удобный способ импорта файлов журналов в таблицу базы данных. Эта опция выводит строки журнала в формате с разделением запятыми (CSV), со следующими столбцами: метка времени с миллисекундами, имя пользователя, имя базы данных, идентификатор процесса, клиент хост: номер порта, идентификатор сеанса, номер строки за сессию, тег команды, время начала сеанса, виртуальный идентификатор транзакции, обычный идентификатор транзакции, серьезность ошибки, код SQLSTATE, сообщение об ошибке, подробное сообщение об ошибке, подсказка, внутренний запрос, который привел к ошибке (если есть), количество символов позиции ошибки, контекст ошибки, пользовательский запрос, который привел к ошибке (если есть и включен log_min_error_statement), количество символов позиции ошибки, местоположение ошибки в исходном коде PostgreSQL (если log_error_verbosity установлено на verbose), имя приложения, тип бэкенда, идентификатор процесса ведущего параллельной группы и идентификатор запроса. Вот пример определения таблицы для хранения выходных данных журнала в формате CSV:
CREATE TABLE postgres_log
(
log_time timestamp(3) with time zone,
user_name text,
database_name text,
process_id integer,
connection_from text,
session_id text,
session_line_num bigint,
command_tag text,
session_start_time timestamp with time zone,
virtual_transaction_id text,
transaction_id bigint,
error_severity text,
sql_state_code text,
message text,
detail text,
hint text,
internal_query text,
internal_query_pos integer,
context text,
query text,
query_pos integer,
location text,
application_name text,
backend_type text,
leader_pid integer,
query_id bigint,
PRIMARY KEY (session_id, session_line_num)
);
Чтобы импортировать файл журнала в эту таблицу, используйте команду COPY FROM :
COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
Также возможно получить доступ к файлу как к внешней таблице с помощью предоставленного модуля file_fdw.
Нужно сделать несколько шагов для упрощения импорта файлов журнала CSV:
- Установите
log_filenameиlog_rotation_age, чтобы обеспечить согласованную, предсказуемую схему именования для файлов журналов. Это позволяет предсказать, каким будет имя файла, и знать, когда отдельный файл журнала завершен и поэтому готов к импорту. - Установите
log_rotation_sizeравным 0, чтобы отключить ротацию журнала на основе размера, так как это затрудняет предсказание имени файла журнала. - Установите
log_truncate_on_rotationравнымon, чтобы старые данные журнала не смешивались с новыми в одном и том же файле. - Определение таблицы выше включает спецификацию первичного ключа. Это полезно для защиты от случайного импорта одной и той же информации дважды. Команда
COPYфиксирует все данные, которые она импортирует за один раз, поэтому любая ошибка приведет к сбою всего импорта. Если импортируется частичный файл журнала и позже снова импортируется файл после его завершения, нарушение первичного ключа вызовет сбой при импорте. Дождитесь завершения и закрытия журнала перед импортом. Эта процедура также защитит от случайного импорта неполной строки, которая еще не была полностью записана, что также привело бы к повреждениюCOPY.
Использование вывода журнала в формате JSON
Включение jsonlog в список log_destination предоставляет удобный способ импорта файлов журнала в различные программы. Эта опция выводит строки журнала в формате JSON.
Строковые поля с пустыми значениями исключаются из вывода. В будущем могут быть добавлены дополнительные поля. Пользовательские приложения, которые обрабатывают вывод jsonlog, должны игнорировать неизвестные поля.
Каждая строка журнала сериализуется как объект JSON с набором ключей и их соответствующими значениями, показанными в таблице ниже.
Ключ и значение записей журнала JSON:
| Имя ключа | Тип | Описание |
|---|---|---|
timestamp | строка | Метка времени с миллисекундами |
user | строка | Имя пользователя |
dbname | строка | Имя базы данных |
pid | число | Идентификатор процесса |
remote_host | строка | Хост клиента |
remote_port | число | Клиентский порт |
session_id | строка | Идентификатор сеанса |
line_num | число | Номер строки за сеанс |
ps | строка | Текущее отображение ps |
session_start | строка | Время начала сеанса |
vxid | строка | Виртуальный идентификатор транзакции |
txid | строка | Регулярный идентификатор транзакции |
error_severity | строка | Серьезность ошибки |
state_code | строка | Код состояния SQLSTATE |
message | строка | Сообщение об ошибке |
detail | строка | Подробности сообщения об ошибке |
hint | строка | Подсказка сообщения об ошибке |
internal_query | строка | Внутренний запрос, который привел к ошибке |
internal_position | число | Индекс курсора во внутреннем запросе |
context | строка | Контекст ошибки |
statement | строка | Строка запроса, предоставленная клиентом |
cursor_position | число | Курсорный индекс в строку запроса |
func_name | строка | Функция имени местоположения ошибки |
file_name | строка | Имя файла места ошибки |
file_line_num | число | Номер строки файла места ошибки |
application_name | строка | Имя клиентского приложения |
backend_type | строка | Тип бэкенда |
leader_pid | число | Идентификатор процесса лидера для активных параллельных рабочих процессов |
query_id | число | Идентификатор запроса |
Название процесса
Эти настройки управляют тем, как изменяются заголовки процессов серверных процессов. Заголовки процессов обычно просматриваются с помощью программ, таких как ps или, в Windows, Process Explorer. См. раздел Стандартные инструменты Unix для получения подробной информации.
cluster_name (string)
Устанавливает имя, которое идентифицирует этот кластер баз данных (экземпляр) для различных целей. Имя кластера появляется в заголовке процесса для всех серверных процессов в этом кластере. Кроме того, это стандартное имя приложения для подключения резервного копирования (см. synchronous_standby_names).
Имя может быть любой строкой длиной менее NAMEDATALEN символов (64 символа в стандартной сборке). В значении cluster_name могут использоваться только печатные символы ASCII. Остальные символы заменяются шестнадцатеричными спецсимволами в стиле C. Никакое имя не отображается, если этот параметр установлен в пустую строку '' (что является значением по умолчанию). Этот параметр можно установить только при запуске сервера.
update_process_title (boolean)
Включает обновление заголовка процесса каждый раз, когда сервер получает новую команду SQL. Эта настройка по умолчанию установлена на on на большинстве платформ, но она установлена на off в Windows из-за большей нагрузки этой платформы для обновления заголовка процесса. Только суперпользователи и пользователи с соответствующим привилегией SET могут изменить эту настройку.