PostgreSQL и логи

klink0v — 12.07.2024

Чё-то меня торкнуло пойти разбираться как устроено логирование в PostgreSQL. Короткий ответ: непросто.

А в чём вообще суть проблемы, спросите вы?

Очень многие разработчики пытаются оптимизировать свои запросы к базе данных, для чего им требуется какая-нибудь более-менее наглядная статистика из серии "что выполняется быстро, что медленно". Некоторые из них для этой цели требуют развернуть для них pgbadger. Который парсит логи Postgres-а и формирует ту самую статистику.

Однако если база достаточно нагруженная и отсечка логирования по времени выполнения выставлена достаточно низкая, то логи загаживают пространство на диске со страшной скоростью. Полгигабайта в сутки — это, считай, так, ни о чём, побаловаться только в одном-единственном проекте. Соответственно, после обсчета статистики логи нужно как-то ротировать-чистить и всё в этом духе, иначе никаких дисков не хватит.

У Postgres-а под Linux-ом предусмотрено три основных способа логирования (всякие хипстерские JSON в расчет не берем): stderr, syslog, собственный коллектор. И они ни разу не тождественные. Вот в этой доке описаны нюансы работы каждого из них.

По умолчанию в Debian-системах "из коробки" включен первый способ (stderr). Проверить это можно псевдо-SQL запросом вида "show log_destination;" в psql-клиенте. В момент старта демона утилита pg_ctl подменяет ему файловый дескриптор stderr на файл в директории "/var/log/postgresql", поэтому для пользователя системы это выглядит так, как будто Postgres пишет логи напрямую в файл. Собственно, так оно и есть, но... мы не можем делать ротацию такого лога иначе как методом copytruncate. Что превращает работу с жирными логами в весьма ресурсоёмкую задачу. Кроме того, постоянно открытый дескриптор на супержирный файл приводит к тому, что он не может "вымыться" из кеша VFS, понапрасну расходуя оперативную память. Плохо.

Встроенный постгресовский лог-коллектор — фичастая, разухабистая и весьма мощная штука. Но он заточен под то, чтобы "не потерять ни единой записи". Как следствие, если этот коллектор по каким-то причинам затупит под нагрузкой (например, почему-то начал медленно отвечать носитель, на который он пишет), то следом за ним станет тупить и основной процесс Postgres-а. То есть фактически на ровном месте произойдёт деградация сервиса. Совсем плохо.

Остается syslog. Вроде как он лишен недостатков предыдущих двух методов. Вопрос только в том что дальше делать с данными, которые в этот syslog сваливаются. Если пихать их по умолчанию в общесистемный бинарный journald, то оный очень быстро забьется, в нём все перемешается и на фоне сообщений Postgres-а искать какие-то другие системные события будет весьма затруднительно. Да и фильтрация одних от других тоже будет на таких объемах происходить небыстро.

Для себя я вижу только выход переключать выхлоп Postgres-а в отдельный инстанс (Log Namespace) journald, хранилище которого размещать на отдельной файловой системе. Как это делать, я уже писал раньше. Благо, pgBadger в числе прочего умеет работать и с journalctl тоже. Пожалуй, единственный недостаток — придется объяснять разработчикам где отныне лежат логи и как их смотреть. Но это не самая большая проблема, поэтому по всей вероятности пойду как раз этим путём.

Всем информативных логов и удобной работы с ними.

Оставить комментарий

Популярные посты:

sabinus

Какие ЖК Казани предлагают квартиры с ремонтом

• Ранее
• Архив