Как поместить логи sql в журнал application

Способы логирования Hibernate

Приветствую, дорогие друзья! Меня зовут Алексей, и я backend java developer. На одном из моих проектов была задача — предоставлять по требованию SQL запросы уходящие в БД, для этого их решили логировать. В этой статье я постараюсь поделиться несколькими способами, которыми можно достичь данной задачи.

Проект был написан на Spring, поэтому все примеры будут на нём. Запросы были написаны с использованием JPA или сгенерированы через Spring Repository.

Первый и самый проcтой способ: залогировать запросы Hibernate

Указать в application.properties: spring.jpa.show-sql=true

Так мы можем быстро решить проблему с локальным поиском багов, но есть несколько очевидных минусов:

1. Вывод SQL не проходит через наш логгер и не имеет необходимый для нас формат. Запрос просто уходит в System.out.

2. Вместо параметров запроса мы видим вопросики.

Второй подход: установка уровня логирования

Пример на основе application.properties: logging.level.org.hibernate.SQL=debug

Изменение уровня логов пакета SQL на debug добавит в наш лог sql запросы.

Изменение же уровня BasicBinder на trace добавит нам параметры запросы, правда в слегка непривычной форме — поочередное перечислением после самого запроса.

Третий подход: использование proxy драйвера

Например log4jdbc или p6spy . Оба прокси рабочие и на них есть стартеры, хотя на log4jdbc давно не было коммитов на момент написание статьи.

В принципе, нашей цели мы добились. Но есть одна проблема: иногда запросов очень много, а нам нужны только несколько. Расскажу на примере p6spy один из способов этого добиться.

Во-первых у нас есть ограничение в самой библиотеке.

В properties можно указать pattern по которому будут фильтроваться логируемые запросы.

покажет нам все insert запросы.

Но иногда нам нужно выводить в лог всего один или несколько методов. Сделаем реализацию такой аннотации сами. Объявим аннотацию:

По сути нам нужно отфильтровать нужные логи по какому то признаку. Я решил сделать это с помощью MDC, у него область видимости как раз ThreadLocal, что нам на руку. Сделаем фильтр:

Обработчик аннотации я сделал через аспект:

ну и конфигурация на примере Logback :

Создадим дополнительный appender с фильтром и пропустим через него логи p6spy уровня info и не забудем указать additivity=«false» , что бы root appender не обрабатывал этот же пакет. Вот и всё.

Не забываем, что мы сделали это через proxy, а значит у нас есть ограничения в выборе методов, над которыми можно ставить новую аннотацию.

Заключение: Как мы видим в логирование Hibernate нет ничего сложного. Последний подход даёт возможность легко помечать аннотацией только те методы которые нужны.

Была ли у Вас необходимость логировать запросы? Какой подход использовали? Пишите в комментариях.

How can I log SQL statements in Spring Boot?

I have the following properties in application.properties :

When I run my application,

I can see SQL statements in the console, but they don’t appear in app.log. The file contains only basic logs from Spring.

What should I do to see SQL statements in the log file?

23 Answers 23

Try using this in your properties file:

This works for standard output too:

Just add this to application.properties .

This works for me (YAML):

Settings to avoid

You should not use this setting:

The problem with show-sql is that the SQL statements are printed in the console, so there is no way to filter them, as you’d normally do with a Logging framework.

Using Hibernate logging

In your log configuration file, if you add the following logger:

Then, Hibernate will print the SQL statements when the JDBC PreparedStatement is created. That’s why the statement will be logged using parameter placeholders:

If you want to log the bind parameter values, just add the following logger as well:

Once you set the BasicBinder logger, you will see that the bind parameter values are logged as well:

Using datasource-proxy

The datasource-proxy OSS framework allows you to proxy the actual JDBC DataSource , as illustrated by the following diagram:

You can define the dataSource bean that will be used by Hibernate as follows:

Notice that the actualDataSource must be the DataSource defined by the connection pool you are using in your application.

Next, you need to set the net.ttddyy.dsproxy.listener log level to debug in your logging framework configuration file. For instance, if you’re using Logback, you can add the following logger:

Once you enable datasource-proxy , the SQL statement are going to be logged as follows:

Как поместить логи sql в журнал application

Приветствую, дорогие друзья! Меня зовут Алексей, и я backend java developer. На одном из моих проектов была задача — предоставлять по требованию SQL запросы уходящие в БД, для этого их решили логировать. В этой статье я постараюсь поделиться несколькими способами, которыми можно достичь данной задачи.

Проект был написан на Spring, поэтому все примеры будут на нём. Запросы были написаны с использованием JPA или сгенерированы через Spring Repository.

Первый и самый проcтой способ: залогировать запросы Hibernate

Указать в application.properties: spring.jpa.show-sql=true

Так мы можем быстро решить проблему с локальным поиском багов, но есть несколько очевидных минусов:

1. Вывод SQL не проходит через наш логгер и не имеет необходимый для нас формат. Запрос просто уходит в System.out.

2. Вместо параметров запроса мы видим вопросики.

Второй подход: установка уровня логирования

Пример на основе application.properties: logging.level.org.hibernate.SQL=debug

Изменение уровня логов пакета SQL на debug добавит в наш лог sql запросы.

Изменение же уровня BasicBinder на trace добавит нам параметры запросы, правда в слегка непривычной форме — поочередное перечислением после самого запроса.

Третий подход: использование proxy драйвера

Например log4jdbc или p6spy . Оба прокси рабочие и на них есть стартеры, хотя на log4jdbc давно не было коммитов на момент написание статьи.

В принципе, нашей цели мы добились. Но есть одна проблема: иногда запросов очень много, а нам нужны только несколько. Расскажу на примере p6spy один из способов этого добиться.

Во-первых у нас есть ограничение в самой библиотеке.

В properties можно указать pattern по которому будут фильтроваться логируемые запросы.

покажет нам все insert запросы.

Но иногда нам нужно выводить в лог всего один или несколько методов. Сделаем реализацию такой аннотации сами. Объявим аннотацию:

По сути нам нужно отфильтровать нужные логи по какому то признаку. Я решил сделать это с помощью MDC, у него область видимости как раз ThreadLocal, что нам на руку. Сделаем фильтр:

Обработчик аннотации я сделал через аспект:

ну и конфигурация на примере Logback :

Создадим дополнительный appender с фильтром и пропустим через него логи p6spy уровня info и не забудем указать additivity=«false» , что бы root appender не обрабатывал этот же пакет. Вот и всё.

Не забываем, что мы сделали это через proxy, а значит у нас есть ограничения в выборе методов, над которыми можно ставить новую аннотацию.

Заключение: Как мы видим в логирование Hibernate нет ничего сложного. Последний подход даёт возможность легко помечать аннотацией только те методы которые нужны.

Была ли у Вас необходимость логировать запросы? Какой подход использовали? Пишите в комментариях.

Кручу, верчу логи при помощи SQL — облегчаем анализ данных

Бывает такая ситуация, что необходимо проанализировать большой объём данных системы логирования событий на предмет аномалий или инцидентов. Просматривать такой массив данных трудно и нецелесообразно. Для этих целей можно обратиться к специализированному программному обеспечению, но нужно знать к какому. Не всегда есть время на изучение. И хорошо, если под конкретные задачи на примете есть несколько вариантов. А если их нет, тогда как быть?

Выход есть всегда, было бы желание. Поговорим о том, как можно довольно быстро загрузить некий массив таких данных куда-то и заняться его анализом. Для этого нам потребуется уже установленные:

2017 или позднее; (SSMS);
1. Понимание синтаксиса sql-запросов (SQL — Structured Query Language) хотя бы на базовом уровне. Если с этим пунктом есть трудности, можно обратиться к официальной документации Microsoft: Учебник. Составление инструкций Transact-SQL

Проверить версию установленного MS SQL Server можно при помощи sql-запроса в той же SSMS:

Результат выполнения запроса можно наблюдать на изображении ниже.

Или посмотреть версию SQL-сервера в Object Explorer, предварительно подключившись к нему.

Для выполнения sql-запросов использовалась SSMS версии 18.4 (более поздние версии также подойдут).

Internet Information Services и лог-файлы

В качестве эксперимента возьмём лог-файлы за пять дней с трёх серверов, на которых запущен Internet Information Services (IIS).

IIS — это веб-сервер, разработанный компанией Microsoft для своих операционных систем. Продукт полностью проприетарный и идёт в комплекте с Windows. Первая версия появилась в Windows NT и продолжает развиваться. По умолчанию IIS выключён в операционной системе.

Запустим диспетчер служб IIS на одном из серверов через меню «Пуск», написав в поисковой строке слово «IIS». Либо нажмите комбинацию клавиш Win+R, введите %SystemRoot%System32InetsrvInetmgr.exe и щёлкните «Ok».

После запуска диспетчера служб IIS (одним из двух способов) нам необходимо перейти в категорию Sites для определения значения ID. Оно понадобится нам для правильной идентификации каталога с лог-файлами интересующего нас сайта. Нам нужны логи для сайта с >

Затем выбираем в левой секции Sites сайт по имени и затем в правой части раздела IIS нажимаем на Logging.

В группе Log Files находим расположение каталога (поле Directory), куда IIS сохраняет логи и формат сохраняемого файла (поле Format). В нашем случае лог-файлы сохраняется в W3C-формате. Подробнее с этим форматом можно познакомиться на официальном сайте Microsoft в руководстве W3C Logging. Копируем или запоминаем путь основного каталога с лог-файлами.

Чтобы просмотреть, какие поля включены для логирования, нажимаем на кнопку Select Fields. Эти данные понадобятся нам в дальнейшем для составления sql-скрипта и таблицы для хранения этих же значений. Так как мы забираем логи с 3-х машин, то отмеченные поля должны совпадать на всех машинах. Если по каким-то причинам есть расхождения, мы не сможем загрузить данные по логам в SQL ввиду их неконсистентности.

Далее переходим в директорию, куда IIS сохраняет логи. Структура папок будет такая: W3SVC[ID], где ID — значение нужного нам сайта. Забираем каталог с именем W3SVC2 или только часть содержимого этого каталога на локальную машину (логи за отдельный день с одной машины могут весить от 200 до 700 Мб). Эти действия по сохранению логов повторяем для оставшихся серверов.

Общий объём данных лог-файлов, собранных с серверов за 5 дней составил примерно 5 Гб на локальной машине.

Пишем sql-скрипты

Половина работы выполнена. Лог-файлы мы скачали себе локально на машину. Убедились, что все поля в них одинаковые по структуре. Теперь нужно их каким-то образом загрузить в базу данных SQL Server.

Запускаем SSMS и подключаемся к локальному серверу.

Создание базы данных

Для начала нам нужно создать на локальном сервере базу данных (БД). Желательно создать её на твердотельном SSD-диске, чтобы подсистема ввода-вывода не стала узким местом при импорте и выполнении запросов на большом количестве данных. Можно сделать это двумя способами:

1. написать скрипт;
2. создать БД через интерфейс SSMS.

Для первого варианта воспользуемся инструкцией CREATE DATABASE. Более подробно с ней можно ознакомиться в разделе «Создание базы данных» с использованием Transact-SQL (T-SQL) официальной документации Microsoft. Итоговый скрипт будет выглядеть так (после создания скрипта не забываем выполнить его):

Для второго варианта жмём правой кнопкой мыши на раздел с именем Databases и в контекстном меню выбираем пункт New Database.

В появившемся окне указываем имя БД, пути и лимиты на основную БД и её лог при необходимости.

Создание таблицы для хранения данных

Итак, у нас уже создана БД. Создадим таблицу для хранения логов. Для этого сверимся с заголовками, которые находятся в самих лог-файлах. Выберем один такой файл и откроем его. Нас интересует 4-я строка.

Копируем её и убираем значение #Fields:. Разделителем между данными служит пробел. С помощью него превращаем одну строку в набор строк и сверяемся с их количеством. В моём случае их получилось ровно 22. Соответственно, в итоговой таблице будет 22 столбца с такими же именами.

С именами столбцов определились, самое время написать скрипт создания таблицы с инструкцией CREATE TABLE. Подробную информацию о ней смотрите на сайте docs.microsoft.com. Итоговый скрипт будет выглядеть так (после создания скрипта не забываем выполнить его):

Максимальные значения текстовых полей (VARCHAR) подобраны эмпирически и их размера вполне должно хватить для импортируемых данных. Но может возникнуть ситуация, когда импорт будет падать с ошибкой. Так может произойти, когда бот или сканер генерирует в запросах «паразитную» нагрузку и значение не помещается в максимальный размер поля. Тогда можно указать для всех текстовых полей максимальное значение параметром MAX (но лучше так не делать и найти «виновника» в данных для указания конечного размера по полю).

Импорт данных

Для импорта нам понадобятся следующие инструкции T-SQL:

И сам итоговый скрипт.

Примечание. В приведённом sql-скрипте по импорту данных можно обойтись без использования таких операторов, как:

• BEGIN TRANSACTION;
• COMMIT TRANSACTION;
• ROLLBACK TRANSACTION.

Запускаем скрипт и идём наливать чай, так как время выполнения импорта может занять от 2 и более минут в зависимости от объёма данных, находящихся в лог-файлах. Результат выполнения скрипта можно увидеть, если нажать на вкладку Messages.

Импорт завершён. Теперь можно узнать, сколько данных мы загрузили. Для этого выполним такой запрос:

В ходе импорта мы загрузили в таблицу около 12 миллионов записей, с которыми можно уже работать.

Например, можно посмотреть, сколько было запросов, с каких IP-адресов и где сервер возвращал в таких запросах статус 404.

Сразу виден топ IP-адресов по количеству запросов. Это либо боты, либо сканеры. Берём первый IP из списка и смотрим на его запросы. И убеждаемся, что это действительно бот/сканер.

Вот так относительно просто можно заниматься аналитикой «небольшого» объёма данных лог-файлов. И необязательно это могут быть только логи с IIS. Загружать в БД SQL для анализа можно почти всё что угодно, было бы желание.

Как поместить логи sql в журнал application

PostgreSQL поддерживает несколько методов протоколирования сообщений сервера: stderr , csvlog и syslog . На Windows также поддерживается eventlog . В качестве значения log_destination указывается один или несколько методов протоколирования, разделённых запятыми. По умолчанию используется stderr . Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера.

Если в log_destination включено значение csvlog , то протоколирование ведётся в формате CSV (разделённые запятыми значения). Это удобно для программной обработки журнала. Подробнее об этом в Подразделе 20.8.4. Для вывода в формате CSV должен быть включён logging_collector.

Если присутствует указание stderr или csvlog , создаётся файл current_logfiles , в который записывается расположение файла(ов) журнала, в настоящее время используемого сборщиком сообщений для соответствующего назначения. Это позволяет легко определить, какие файлы журнала используются в данный момент экземпляром сервера. Например, он может иметь такое содержание:

current_logfiles переписывается когда при прокрутке создаётся новый файл журнала или когда изменяется значение log_destination . Он удаляется, когда в log_destination не задаётся ни stderr , ни csvlog , а также когда сборщик сообщений отключён.

Примечание

В большинстве систем Unix потребуется изменить конфигурацию системного демона syslog для использования варианта syslog в log_destination . Для указания типа протоколируемой программы (facility), PostgreSQL может использовать значения с LOCAL0 по LOCAL7 (см. syslog_facility). Однако на большинстве платформ конфигурация syslog по умолчанию не учитывает сообщения подобного типа. Чтобы это работало, потребуется добавить в конфигурацию демона syslog что-то подобное:

Для использования eventlog в log_destination на Windows, необходимо зарегистрировать источник событий и его библиотеку в операционной системе. Тогда Windows Event Viewer сможет отображать сообщения журнала событий. Подробнее в Разделе 19.12.

Параметр включает сборщик сообщений (logging collector). Это фоновый процесс, который собирает отправленные в stderr сообщения и перенаправляет их в журнальные файлы. Такой подход зачастую более полезен чем запись в syslog , поскольку некоторые сообщения в syslog могут не попасть. (Типичный пример с сообщениями об ошибках динамического связывания, другой пример — ошибки в скриптах типа archive_command .) Для установки параметра требуется перезапуск сервера.

Примечание

Можно обойтись без сборщика сообщений и просто писать в stderr . Сообщения будут записываться в место, куда направлен поток stderr . Такой способ подойдёт только для небольших объёмов протоколирования, потому что не предоставляет удобных средств для организации ротации журнальных файлов. Кроме того, на некоторых платформах отказ от использования сборщика сообщений может привести к потере или искажению сообщений, так как несколько процессов, одновременно пишущих в один журнальный файл, могут перезаписывать информацию друг друга.

Примечание

Сборщик спроектирован так, чтобы сообщения никогда не терялись. А это значит, что при очень высокой нагрузке, серверные процессы могут быть заблокированы при попытке отправить сообщения во время сбоя фонового процесса сборщика. В противоположность этому, syslog предпочитает удалять сообщения, при невозможности их записать. Поэтому часть сообщений может быть потеряна, но система не будет блокироваться.

При включённом 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. Когда протоколировать

Управляет минимальным уровнем сообщений, записываемых в журнал сервера. Допустимые значения 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_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.

Русские Блоги

MS Информация журнала / записи журнала SQL могут быть вам знакомы и незнакомы. Знакомо, потому что вы, возможно, использовали его. Проверьте и обратите внимание на некоторую информацию / записи журнала, например , История заданий; это незнакомо, потому что означает, что вы никогда не сможете обращать внимание на управление информацией / записями журнала. Здесь я всегда использую термин информация / запись журнала вместо термина файл журнала. Вкратце, я хочу, чтобы все отличили его от файла журнала транзакций (ldf) . В Интернете, если вы используете файл журнала в качестве ключевого слова для поиска, вы можете найти информацию, относящуюся к журналу транзакций. . Фактически, это действительно называется файлом журнала. В этой статье я, вероятно, начну с классификации записей журнала, того, как просматривать записи журнала, местоположения записей журнала, настроек записей журнала и почему журнал ошибок будет увеличиваться , Как очистить записи журнала и так далее.

Классификация записей журнала

Согласно программе просмотра файлов журнала, журнал ошибок обычно классифицируется как SQL SERVER, агент SQL SERVER, журнал приложений Windows, почта базы данных и другие четыре типа записей журнала ошибок. Если вы также учитываете план обслуживания, план удаленного обслуживания и информацию журнала истории заданий, то всего существует 7 типов файлов информации журнала.

Среди них типы журналов приложений Windows делятся на системный журнал (System), журнал безопасности (Security), журнал приложений (Application), журнал PatchLink. Дождавшись нескольких, я открыл SSMS на сервере (Windows Server 2008 R2 Standard) и обнаружил, что есть еще HardwareEvents, Internet Explorer, Windows PowerShell. Дождитесь файлов журнала. Это файлы журнала системы. Вам не нужно слишком беспокоиться о том, сколько их видов.

Место регистрации

Расположение записей журнала SQL SERVER и записей прокси SQL SERVER следующее. Записи журнала SQL SERVER обычно хранятся в файле ERRORLOG.n (n — число), SQL Записи журнала агента SERVER находятся в таких файлах, как SQLAGENT.n. Конечно, это также связано с версией базы данных:

SQL SERVER 2005

Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\LOG

SQL SERVER 2008

C: \ Program Files \ Microsoft SQL Server \ MSSQL10.Имя экземпляра \ MSSQL \ LOG

SQL SERVER 2008 R2

C: \ Program Files \ Microsoft SQL Server \ MSSQL10_50.Имя экземпляра \ MSSQL \ LOG

SQL SERVER 2005 по умолчанию журнал ошибок находится в Program Files \ Microsoft SQL Server \ MSSQL.n\ MSSQL \ LOG \ ERRORLOG и ERRORLOG.n Файл. Отличие MSSQL.n:

Поэтому в целом вам нужно обращать внимание только на файлы журналов в каталоге MSSSQL.1.

Итак, где же находятся записи журнала электронной почты базы данных? Где находятся данные журнала истории заданий и журнал приложений Windows? Вы никогда не задумывались об этом?

Информацию журнала почты базы данных можно запросить из представления msdb.dbo.sysmail_event_log, которое по существу хранится в таблице [dbo]. [Sysmail_log].

1. SELECT log_id ,
2. CASE event_type
3. WHEN 0 THEN ‘success’
4. WHEN 1 THEN ‘information’
5. WHEN 2 THEN ‘warning’
6. ELSE ‘error’
7. END AS event_type ,
8. log_date ,
9. description ,
10. process_id ,
11. sl . mailitem_id ,
12. account_id ,
13. sl . last_mod_date ,
14. sl . last_mod_user
15. FROM [dbo] . [sysmail_log] sl
16. WHERE ( ISNULL ( IS_SRVROLEMEMBER ( N’sysadmin’ ), 0 ) = 1 )
17. OR ( EXISTS ( SELECT mailitem_id
18. FROM [dbo] . [sysmail_allitems] ai
19. WHERE sl . mailitem_id = ai . mailitem_id ) )

Информация журнала истории заданий хранится в таблице msdb.dbo.sysjobhistory, где поле run_status представляет статус выполнения задания.

0 = Ошибка

1 = Успех

2 = Повторить

3 = Отменено

4= В процессе

Все журналы приложений Windows фактически находятся в в том же месте% SystemRoot% \ System32 \ Winevt \ Log. Как и файл журнала приложения, расположенный в% SystemRoot% \ System32 \ Winevt \ Logs \ Application.evtx, как показано ниже,

Просмотр записей журнала

Просмотр записей журнала может гарантировать, что процессы (например, операции резервного копирования и восстановления, пакетные команды или другие сценарии и процессы) завершены успешно. Эта функция может использоваться для обнаружения любых текущих или потенциальных проблемных областей, включая сообщения автоматического восстановления (особенно, когда экземпляр SQL Server был остановлен и перезапущен), сообщения ядра или другие сообщения об ошибках на уровне сервера.

Метод 1. Просмотрите файл журнала ошибок.

Для информации журнала SQL SERVER, SQL SERVER AGENT вы можете перейти непосредственно в каталог журнала, чтобы найти файлы журнала ERRORLOG, SQLAGENT, а также напрямую открыть и просмотреть; а также Как и запись журнала приложения Windows , перейдите в каталог% SystemRoot% \ System32 \ Winevt \ Log, найдите соответствующий файл журнала и откройте его напрямую.

Метод 2: просмотр записей журнала через SSMS

Просмотр журналов, относящихся к общей активности SQL Server

1. В обозревателе объектов разверните"менеджмент"с участием«Журнал SQL Server», Двойной щелчок"текущий<Дата / Время>”, ПокажетSQL Server、«Агент SQL»с участием«Событие Windows»Журнал.

Просмотр журналов, связанных с заданием

1. В обозревателе объектов разверните«Агент SQL Server», Щелкните правой кнопкой мыши"операция", Затем щелкните"Посмотреть историю", Он покажет"История вакансий"с участием«Агент SQL»Журнал.

Просмотр журналов, связанных с планом обслуживания

1. В обозревателе объектов разверните"менеджмент", Щелкните правой кнопкой мыши«План обслуживания», Затем щелкните"Посмотреть историю", Он покажет«План обслуживания»、"История вакансий"с участием«Агент SQL»Журнал.

Метод 3: просмотр с помощью скрипта

3.1 Файл журнала SQL SERVER можно просмотреть с помощью следующего сценария:

-Просмотр номера архива файла журнала

Вы можете использовать эту команду для просмотра размера файла журнала. Это очень полезно. Вы можете отсортировать файлы с ненормальными размерами.

— Просмотр содержимого журнала файла в соответствии с номером архива

EXEC master.dbo.xp_readerrorlog 1

— Просмотр записей журнала SQL SERVER в соответствии с job_id

SELECT * FROM msdb.dbo.sysjobhistory WHERE job_id=’36E9232B-CD5B-4646-9BED-B8242090FFF9′

3.2 Информацию журнала истории заданий можно просмотреть с помощью следующей хранимой процедуры или напрямую запросить соответствующую таблицу.

Например, я хочу просмотреть историю задания "ServerDiskCapacityCheck"

1. USE msdb ;
2. GO
3. EXEC dbo . sp_help_jobhistory
4. @job_name = N’ServerDiskCapacityCheck’ ;
5. GO
6. »ò
7. SELECT j . name AS [JOB_NAME] ,
8. h . step_id AS [Step] ,
9. h . step_name AS [STEP_NAM] ,
10. h . MESSAGE AS [Message] ,
11. [Status] = CASE WHEN h . run_status = 0 THEN ‘Failed’
12. WHEN h . run_status = 1 THEN ‘Succeeded’
13. WHEN h . run_status = 2 THEN ‘Retry’
14. WHEN h . run_status = 3 THEN ‘Canceled’
15. END ,
16. h . run_date AS [RunDate] ,
17. h . run_time AS [RunTime] ,
18. h . run_duration AS [RunDuration]
19. FROM sysjobs j
20. INNER JOIN sysjobhistory h ON h . job_id = j . job_id
21. WHERE h . run_date >= CONVERT ( CHAR ( 8 ), GETDATE ()- 1 , 112 ) AND h . run_status <> 1
22. /* WHERE j.name = ‘Job_Name’ */
23. ORDER BY h . run_date , h . run_time

3.3 Просмотр записи почты базы данных

SELECT * FROM msdb.dbo.sysmail_event_log;

Управление записями журнала

Установите максимальное количество файлов журнала ошибок

1: вОбозреватель объектов, Подключитесь к экземпляру ядра СУБД SQL Server, а затем разверните экземпляр.

2: В параметре «Управление» выберите «Журнал SQL SERVER», щелкните правой кнопкой мыши, чтобы выбрать конфигурацию. Кстати, во многих онлайн-материалах говорится, что SQL SERVER по умолчанию сохраняет первые 6 файлов журнала, но я проверил SQL SERVER 2005 и SQL SERVER 2008, и оба по умолчанию сохраняют 30. Иногда Проверять и экспериментировать нужно самому, а не всем. Предполагается, что этот оператор является конфигурацией SQL SERVER 2000.

Конечно, вы также можете использовать команду для установки:

Задайте каталог хранения файла журнала ошибок

1: вОбозреватель объектов, Подключитесь к экземпляру ядра СУБД SQL Server, а затем разверните экземпляр.

2: Разверните агент «SQL SERVER».

3: Щелкните правой кнопкой мыши «Журнал ошибок» и выберите параметры конфигурации, как показано ниже:

4: В поле «файл журнала ошибок» введите новый путь и имя файла или используйте кнопку обзора (. ) для поиска. После перезапуска службы агента SQL SERVER агент SQL SERVER записывает в новый файл журнала.

Установить журнал истории заданий

1. вОбозреватель объектов, Подключитесь к экземпляру ядра СУБД SQL Server, а затем разверните экземпляр.
2. Щелкните правой кнопкой мыши«Агент SQL Server», Затем щелкните«Атрибуты»。
3. в«Свойства агента SQL Server»В диалоговом окне выберите"исторический рекорд"страница.
4. Выберите один из следующих вариантов:

• Выбрано«Ограничить размер журнала истории заданий», А затем введите максимальное количество строк в журнале истории заданий и максимальное количество строк на задание.
• Выбрано«Автоматически удалять историю агента», А затем укажите период времени. Таким образом, записи истории до этого периода времени будут удалены из журнала.

Почему взрывается файл журнала ошибок?

Я говорю здесь не только о взрыве определенного файла журнала ошибок, но и о каталоге Program Files \ Microsoft SQL Server \ MSSQL.nПространство, занимаемое \ MSSQL \ LOG, резко возросло. Если вы обычно не обращаете внимания на эти журналы ошибок и никогда не ведете записи журнала ошибок, то вполне вероятно, что пространство, занимаемое им, очень велико, настолько велико, что это вас удивит. Я видел десятки гигабайт, поэтому конкретные причины могут быть следующими (если вы столкнулись с другими ситуациями, добавьте их):

1: при возникновении внутренней ошибки SQL будет создано много файлов DUMP, как показано ниже.

2: Сервер базы данных с высокой доступностью может редко останавливаться, и вы не выполняете регулярную очистку, очищаете эту информацию журнала ошибок, тогда рост файла ERRORLOG.n / SQLAGENT.n будет очень большим. Таким образом, администратору базы данных будет сложнее использовать журнал ошибок для поиска информации, а производительность будет снижена после загрузки и записи журнала.

3: На самом деле, есть другая ситуация: если IP-адрес вашей базы данных открыт во внешней сети, вы подвергнетесь атаке из-за большого количества попыток входа в sa, а также будет сгенерировано большое количество сообщений журнала ошибок аудита.

4: Некоторые файлы SQL SERVER PROFILE не удаляются .. Конечно, эта суть не имеет ничего общего с всплеском файлов журналов, но имеет какое-то отношение к размеру папки LOG.

Как очистить журнал ошибок:

Для журнала SQL SERVER, записи журнала SQL SERVER AGENT, Microsoft предоставляет хранимую процедуру sp_cycle_errorlog для реализации цикла журнала. Функция этой хранимой процедуры — закрыть текущий файл журнала ошибок и зациклить номер расширения журнала ошибок (как при перезапуске сервера). Каждый раз при запуске SQL Server текущий журнал ошибок будет переименован вerrorlog.1；errorlog.1 Становитсяerrorlog.2，errorlog.2 Становитсяerrorlog.3,И так далее. Последний errorlog.n будет удален.sp_cycle_errorlog Позволяет циклически просматривать файл журнала ошибок без необходимости останавливать и запускать сервер.

Кроме того: если журнал слишком велик, это означает, что вы не усекли журнал ошибок. Журнал ошибок можно усечь. Введите DBCC ERRORLOG в свою базу данных.

Каждый раз, когда выполняется текущий журнал ошибок, текущий журнал ошибок закрывается и создается новый журнал ошибок . Вы можете удалить только журнал ошибок ERRORLOGn. Журнал без номера является используемым журналом. Если вы удалите его, будет сообщено об ошибке. Он относительно большой, просто DBCC ERRORLOG, а затем он станет ERRORLOG + number, вы можете удалить его, и рекомендуется поместить эти ERRORLOG в другие буквы диска для лучшего управления.

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

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

sysmail_delete_log_sp [ [ @logged_before = ] ‘logged_before‘ ]

[, [ @event_type = ] ‘event_type‘ ]

Удалите все журналы шагов задания агента SQL Server, указанные в параметре. Используйте эту хранимую процедуру для обслуживанияmsdbВ базеsysjobstepslogsСтол.

[ , [ @step_id = ] step_id | [ @step_name = ] ‘step_name’ ]

Удалить историю вакансий

Удалить историю конкретного задания YourSQLDba_LogBackups.

В следующем примере этот процесс будет выполнен без параметров для удаления всех записей истории.

Удалите все журналы шагов задания агента SQL Server, указанные в параметре. Используйте эту хранимую процедуру для обслуживанияmsdb В базеsysjobstepslogs стол. Если вы хотите хорошо поддерживать записи журнала, вы можете интегрировать вышеупомянутые идеи в хранимую процедуру, а затем настроить задание на регулярную очистку записей журнала.Далее давайте взглянем на метод YourSQLDba.

Как поместить логи sql в журнал application

В статье дается обзор журналов SQL Server для управления и устранения неполадок на сервере.

Введение

Администратор базы данных может также сконфигурировать SQL Server для выполнения дополнительных записей в журналы ошибок. Например, мы можем включить флаг трассировки для захвата информации о тупиковых ситуациях. DBA должен регулярно просматривать эти журналы в поисках потенциальных проблем. Вы можете обнаружить в журналах такую информацию, как сбой резервного копирования, ошибки входа, ошибки ввода-вывода. Эти журналы ошибок являются отличным средством для обнаружения существующих и потенциальных проблем в экземплярах SQL Server.

Журналы SQL Server известны как SQL Server Error logs. Журналы ошибок содержат информационные сообщения, предупреждения и сообщения о критичных ошибках. Вы можете просматривать некоторые из этих журналов также в просмотрщике событий Windows. Однако рекомендуется использовать журналы SQL Server для получения подробной информации.

Журналы SQL Server и их местонахождение

Если вы подключены к экземпляру SQL Server в SSMS, перейдите к Management -> SQL Server Logs. Как показано ниже, имеется текущий журнал и шесть архивных журналов (Archive#1 — Archive #6).

Метод 1: Использование расширенной процедуры xp_readerrorlog

Текущие журналы являются самыми последними файлами журнала ошибок, и вы можете использовать их для просмотра недавней деятельности с момента запуска SQL Server или ручного перезапуска файла журнала. Журнал ошибок SQL Server является текстовым файлом, хранящимся в каталоге журналов экземпляра SQL Server. Вы можете использовать расширенную процедуру xp_readerrorlog для нахождения текущего местоположения журнала ошибок.

Метод 2: Использование функции SERVERPROPERTY()

Мы можем использовать в запросе функцию SERVERPROPERTY, и также определить местонахождение SQL Server ERRORLOG.

Метод 3: использование менеджера конфигурации SQL Server

Откройте SQL Server Configuration Manager и посмотрите параметры запуска. Местоположение файлов журнала указывается с помощью переключателя -e.

Вы можете развернуть каталог журналов и просмотреть текущий или архивные файлы журнала. Эти журналы ошибок можно открыть в текстовом редакторе, таком как Notepad или Visual Studio Code.

Конфигурирование числа файлов журнала SQL Server и их размеров

По умолчанию SQL Server поддерживает текущий и 6 архивных файлов журнала. Чтобы уточнить значение, выполните щелчок правой кнопкой на папке SQL Server Logs в SSMS и выберите Configure.

SQL Server позволяет сконфигурировать от 6 до 99 файлов журнала ошибок. Вы не можете указать значение меньше шести, поскольку в любом случае будет поддерживаться шесть архивных журналов ошибок.

Для изменения значения по умолчанию числа файлов журнала ошибок поставьте галочку в поле с названием “Limit the number of error log files before they are recycled”. Например, следующий скриншот показывает максимальное число файлов журнала ошибок, равное 30.

Это эквивалентно выполнению скрипта T-SQL, который использует расширенную хранимую процедуру и обновляет значение регистра.

Замечание. Следует перезапустить службу SQL, чтобы изменения вступили в силу.

Как утверждалось ранее, по умолчанию размер журнала ошибок не ограничен. Например, если вы не запускаете SQL Server в течение длительного периода и вручную не перегружаете файлы журнала, этот файл вырастет до громадных размеров. Поэтому в конфигурации журнала ошибок показано значение 0, соответствующее неограниченному размеру журнала.

Вы можете задать размер в Кб для ограничения размера журнала ошибок в соответствии с вашими требованиями. Например, здесь мы ограничиваем размер файла журнала в 1Гб.

Эквивалентный скрипт T-SQL обновляет ErrorLogSizeInKb в регистре SQL Server.

Перезагрузка журналов ошибок вручную

SQL Server позволяет вручную перегружать журналы ошибок для эффективного управления ими. Например, предположим, что вы увеличили число файлов журнала ошибок до 30. Тогда мы можем создать задание для агента SQL Server, который перегружает журналы ошибок в полночь. Тем самым мы имеем файл журнала ошибок на каждый день, если SQL Server не будет перезапущен в этом промежутке. Для перезагрузки вручную выполните системную хранимую процедуру sp_cycle_errorlog. Эту процедуру может выполнить пользователь с фиксированной серверной ролью sysadmin.

Файл журнала SQL Server Agent

Агент SQL Server также имеет отдельный журнал ошибок, подобный журналам SQL Server. Вы можете обнаружить его в папке SQL Server Agent – > Error logs.

Щелкните правой кнопкой на папке Error log и выберите команду Configure. Это даст местоположение журнала ошибок агента и уровень журнала агента.

Файл журнала агента имеет расширение *.OUT и хранится в папке log при конфигурации по умолчанию. Например, в моей системе файл журнала находится здесь: C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\Log\SQLAGENT.OUT.

Чтобы добавить информационное сообщение, поставьте галочку в поле Information.

SQL Server использует до 9 файлов журнала агента SQL Server. Имя текущего файла SQLAGENT.OUT. Файл с расширением .1 указывает на первый архивный журнал ошибок агента. Аналогично расширение .9 указывает на 9-й (самый старый) архив журнала ошибок.

Файлы журнала агента SQL Server перегружаются всякий раз, когда перезапускается SQL Server Agent. Для того, чтобы сделать это вручную, выполните щелчок правой кнопкой на папке Error Logs folder и выберите Recycle.

Или используйте хранимую процедуру sp_cycle_agent_errorlog для перезагрузки файлов журнала агента SQL Server вручную.

Как поместить логи sql в журнал application

PostgreSQL поддерживает несколько методов протоколирования сообщений сервера: stderr , csvlog и syslog . На Windows также поддерживается eventlog . В качестве значения log_destination указывается один или несколько методов протоколирования, разделённых запятыми. По умолчанию используется stderr . Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера.

Если в log_destination включено значение csvlog , то протоколирование ведётся в формате CSV (разделённые запятыми значения). Это удобно для программной обработки журнала. Подробнее об этом в Подразделе 20.8.4. Для вывода в формате CSV должен быть включён logging_collector.

Если присутствует указание stderr или csvlog , создаётся файл current_logfiles , в который записывается расположение файла(ов) журнала, в настоящее время используемого сборщиком сообщений для соответствующего назначения. Это позволяет легко определить, какие файлы журнала используются в данный момент экземпляром сервера. Например, он может иметь такое содержание:

current_logfiles переписывается когда при прокрутке создаётся новый файл журнала или когда изменяется значение log_destination . Он удаляется, когда в log_destination не задаётся ни stderr , ни csvlog , а также когда сборщик сообщений отключён.

Примечание

В большинстве систем Unix потребуется изменить конфигурацию системного демона syslog для использования варианта syslog в log_destination . Для указания типа протоколируемой программы (facility), PostgreSQL может использовать значения с LOCAL0 по LOCAL7 (см. syslog_facility). Однако на большинстве платформ конфигурация syslog по умолчанию не учитывает сообщения подобного типа. Чтобы это работало, потребуется добавить в конфигурацию демона syslog что-то подобное:

Для использования eventlog в log_destination на Windows, необходимо зарегистрировать источник событий и его библиотеку в операционной системе. Тогда Windows Event Viewer сможет отображать сообщения журнала событий. Подробнее в Разделе 19.12.

Параметр включает сборщик сообщений (logging collector). Это фоновый процесс, который собирает отправленные в stderr сообщения и перенаправляет их в журнальные файлы. Такой подход зачастую более полезен чем запись в syslog , поскольку некоторые сообщения в syslog могут не попасть. (Типичный пример с сообщениями об ошибках динамического связывания, другой пример — ошибки в скриптах типа archive_command .) Для установки параметра требуется перезапуск сервера.

Примечание

Можно обойтись без сборщика сообщений и просто писать в stderr . Сообщения будут записываться в место, куда направлен поток stderr . Такой способ подойдёт только для небольших объёмов протоколирования, потому что не предоставляет удобных средств для организации ротации журнальных файлов. Кроме того, на некоторых платформах отказ от использования сборщика сообщений может привести к потере или искажению сообщений, так как несколько процессов, одновременно пишущих в один журнальный файл, могут перезаписывать информацию друг друга.

Примечание

Сборщик спроектирован так, чтобы сообщения никогда не терялись. А это значит, что при очень высокой нагрузке, серверные процессы могут быть заблокированы при попытке отправить сообщения во время сбоя фонового процесса сборщика. В противоположность этому, syslog предпочитает удалять сообщения, при невозможности их записать. Поэтому часть сообщений может быть потеряна, но система не будет блокироваться.

При включённом 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. Когда протоколировать

Управляет минимальным уровнем сообщений, записываемых в журнал сервера. Допустимые значения 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_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.

Способы логирования Hibernate

Приветствую, дорогие друзья! Меня зовут Алексей, и я backend java developer. На одном из моих проектов была задача — предоставлять по требованию SQL запросы уходящие в БД, для этого их решили логировать. В этой статье я постараюсь поделиться несколькими способами, которыми можно достичь данной задачи.

Проект был написан на Spring, поэтому все примеры будут на нём. Запросы были написаны с использованием JPA или сгенерированы через Spring Repository.

Первый и самый проcтой способ: залогировать запросы Hibernate

Указать в application.properties: spring.jpa.show-sql=true

Так мы можем быстро решить проблему с локальным поиском багов, но есть несколько очевидных минусов:

1. Вывод SQL не проходит через наш логгер и не имеет необходимый для нас формат. Запрос просто уходит в System.out.

2. Вместо параметров запроса мы видим вопросики.

Второй подход: установка уровня логирования

Пример на основе application.properties: logging.level.org.hibernate.SQL=debug

Изменение уровня логов пакета SQL на debug добавит в наш лог sql запросы.

Изменение же уровня BasicBinder на trace добавит нам параметры запросы, правда в слегка непривычной форме — поочередное перечислением после самого запроса.

Третий подход: использование proxy драйвера

Например log4jdbc или p6spy . Оба прокси рабочие и на них есть стартеры, хотя на log4jdbc давно не было коммитов на момент написание статьи.

В принципе, нашей цели мы добились. Но есть одна проблема: иногда запросов очень много, а нам нужны только несколько. Расскажу на примере p6spy один из способов этого добиться.

Во-первых у нас есть ограничение в самой библиотеке.

В properties можно указать pattern по которому будут фильтроваться логируемые запросы.

покажет нам все insert запросы.

Но иногда нам нужно выводить в лог всего один или несколько методов. Сделаем реализацию такой аннотации сами. Объявим аннотацию:

По сути нам нужно отфильтровать нужные логи по какому то признаку. Я решил сделать это с помощью MDC, у него область видимости как раз ThreadLocal, что нам на руку. Сделаем фильтр:

Обработчик аннотации я сделал через аспект:

ну и конфигурация на примере Logback :

Создадим дополнительный appender с фильтром и пропустим через него логи p6spy уровня info и не забудем указать additivity=«false» , что бы root appender не обрабатывал этот же пакет. Вот и всё.

Не забываем, что мы сделали это через proxy, а значит у нас есть ограничения в выборе методов, над которыми можно ставить новую аннотацию.

Заключение: Как мы видим в логирование Hibernate нет ничего сложного. Последний подход даёт возможность легко помечать аннотацией только те методы которые нужны.

Была ли у Вас необходимость логировать запросы? Какой подход использовали? Пишите в комментариях.

How can I log SQL statements in Spring Boot?

I have the following properties in application.properties :

When I run my application,

I can see SQL statements in the console, but they don’t appear in app.log. The file contains only basic logs from Spring.

What should I do to see SQL statements in the log file?

23 Answers 23

Try using this in your properties file:

This works for standard output too:

Just add this to application.properties .

This works for me (YAML):

Settings to avoid

You should not use this setting:

The problem with show-sql is that the SQL statements are printed in the console, so there is no way to filter them, as you’d normally do with a Logging framework.

Using Hibernate logging

In your log configuration file, if you add the following logger:

Then, Hibernate will print the SQL statements when the JDBC PreparedStatement is created. That’s why the statement will be logged using parameter placeholders:

If you want to log the bind parameter values, just add the following logger as well:

Once you set the BasicBinder logger, you will see that the bind parameter values are logged as well:

Using datasource-proxy

The datasource-proxy OSS framework allows you to proxy the actual JDBC DataSource , as illustrated by the following diagram:

You can define the dataSource bean that will be used by Hibernate as follows:

Notice that the actualDataSource must be the DataSource defined by the connection pool you are using in your application.

Next, you need to set the net.ttddyy.dsproxy.listener log level to debug in your logging framework configuration file. For instance, if you’re using Logback, you can add the following logger:

Once you enable datasource-proxy , the SQL statement are going to be logged as follows: