Настройка PostgreSQL мониторинга (pg_stat_statements, pgBadger)
Представьте: вы запускаете новую функциональность, и через час база начинает тормозить. SELECT'ы висят по 30 секунд, а в логах только 'checkpoint time: 200ms'. Что произошло? Без мониторинга это гадание на кофейной гуще. Давайте разберём, как настроить наблюдение за PostgreSQL, чтобы видеть проблему до того, как она станет инцидентом.
Наш опыт показывает: PostgreSQL молчит до последнего. Запросы работают медленно неделями. База выглядит живой, но SELECT на 10 млн строк без индекса использует всю память. Autovacuum не успевает за bloat. Без правильного мониторинга эти проблемы находят себя сами — во время инцидента. Мы настраивали мониторинг для десятков проектов — от стартапов до enterprise-кластеров с терабайтами данных. За более чем 5 лет работы мы реализовали свыше 30 проектов, включая кластеры с репликацией и шардированием.
Почему pg_stat_statements недостаточно для анализа производительности?
pg_stat_statements — первое, что включают после установки PostgreSQL. Расширение агрегирует статистику выполнения запросов: суммарное время, количество вызовов, rows, shared_blks_hit/read. Включается одной строкой в postgresql.conf:
shared_preload_libraries = 'pg_stat_statements' pg_stat_statements.track = all pg_stat_statements.max = 10000 После CREATE EXTENSION pg_stat_statements в целевой базе вьюха pg_stat_statements становится основным инструментом поиска тяжёлых запросов. Запрос для нахождения топ-10 по суммарному времени:
SELECT round(total_exec_time::numeric, 2) AS total_ms,
calls,
round(mean_exec_time::numeric, 2) AS mean_ms,
left(query, 80) AS query_preview
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;Проблема в том, что pg_stat_statements не анализирует логи — только живую статистику в памяти. Исторические данные теряются при рестарте. Для анализа прошедших инцидентов нужен pgBadger. Кроме того, pg_stat_statements не показывает bloat таблиц, lock waits в разрезе сессий, checkpoint activity. Эти метрики критичны для производительности — например, bloat может достигать 40% объёма таблицы, замедляя последовательное сканирование. Документация по pg_stat_statements подтверждает эти ограничения.
Как pgBadger восстанавливает историю инцидентов?
pgBadger парсит postgresql.log и генерирует HTML-отчёт с топом медленных запросов, lock waits, checkpoint warnings, временными файлами. Предварительно нужно настроить правильный формат логов в postgresql.conf:
log_min_duration_statement = 1000 # логировать запросы дольше 1 секунды
log_line_prefix = '%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h '
log_checkpoints = on
log_connections = on
log_disconnections = on
log_lock_waits = on
log_temp_files = 0
lc_messages = 'C' # pgBadger требует английский формат
Генерация отчёта:
pgbadger /var/log/postgresql/postgresql-*.log \
-o /var/www/reports/pgbadger_$(date +%Y%m%d).html \
--format stderr \
--jobs 4Отчёт показывает не просто медленные запросы, а паттерны: в какое время суток нагрузка пиковая, какие приложения генерируют lock waits, сколько временных файлов создаётся (признак нехватки work_mem). На основе отчёта можно делать postmortem — разбирать инцидент шаг за шагом. pg_stat_statements хранит данные только в памяти, а pgBadger — в файлах, позволяя хранить отчёты за месяцы — в 100 раз больше данных. Репозиторий pgBadger на GitHub содержит подробную документацию.
Как postgres_exporter и Grafana обеспечивают оперативный мониторинг?
Для онлайн-метрик используем postgres_exporter от Prometheus Community. Он собирает десятки метрик: размеры баз, активные соединения, состояние репликации, bloat, время последнего vacuum/analyze.
Конфигурация через переменную окружения:
DATA_SOURCE_NAME="postgresql://monitoring_user:password@localhost:5432/postgres?sslmode=disable" Кастомные запросы для queries.yaml позволяют добавить метрики, которых нет в стандартном наборе — например, bloat по таблицам из расширения pgstattuple или lag репликации по каждому слоту.
В Grafana дашборд ID 9628 (PostgreSQL Database) покрывает большинство базовых кейсов. Алерты на критические события:
| Метрика | Порог алерта | Severity |
|---|---|---|
| pg_up = 0 | немедленно | critical |
| Активные соединения > 80% от max_connections | 5 мин | warning |
| Replication lag > 30 сек | 2 мин | warning |
| Возраст транзакции (wraparound) > 1.5 млрд | сразу | critical |
| Dead tuples > 10% от live tuples | 15 мин | warning |
Wraparound — отдельная история. Если age(datfrozenxid) приближается к autovacuum_freeze_max_age (по умолчанию 200 млн транзакций), PostgreSQL сначала замедляется, а потом останавливается полностью и требует ручного VACUUM FREEZE. Алерт на это нужен всегда. Мы рекомендуем ставить предупреждение за 2 дня до предела — этого времени достаточно для внепланового обслуживания.
Сравнение инструментов мониторинга PostgreSQL
| Инструмент | Данные | Хранение | Типичный Use Case |
|---|---|---|---|
| pg_stat_statements | Текущие запросы | В памяти | Поиск тяжёлых запросов в реальном времени |
| pgBadger | Логи PostgreSQL | Файловые отчёты | Исторический анализ, тренды |
| postgres_exporter | Метрики Prometheus | Время-серии | Оперативный дашборд и алерты |
pgBadger в сочетании с postgres_exporter даёт полную картину: первый — для глубинного анализа прошлых событий, второй — для текущего состояния. Это лучше, чем использовать только один инструмент.
Что входит в настройку мониторинга PostgreSQL?
В рамках работ по настройке мониторинга мы предоставляем:
- Аудит текущей конфигурации: проверка параметров логгирования, расширений, политик autovacuum.
- Включение и настройка pg_stat_statements (без рестарта, если возможно).
- Конфигурация pgBadger: настройка формата логов, cron-задания для ежедневной генерации отчётов.
- Деплой postgres_exporter как systemd-сервиса, настройка Prometheus target.
- Импорт и кастомизация Grafana дашборда под вашу архитектуру (реплики, шарды).
- Настройка алертов: wraparound, bloat, lag, активные соединения.
- Документация: описание метрик, runbook по типовым инцидентам.
- Обучение команды: интерпретация отчётов pgBadger, работа с алертами.
Как интерпретировать отчёт pgBadger?
- Top slowest queries: ищем запросы с высоким средним временем и большим числом вызовов.
- Lock waits: при каком приложении возникают блокировки.
- Temporary files: если много — не хватает work_mem, нужно увеличить.
- Checkpoint warnings: слишком частые checkpoint — укорачивается max_wal_size.
- Временной паттерн: пиковая нагрузка на одни и те же часы — возможно, нужно реплицировать чтение.
Сроки и стоимость
Срок настройки — от половины дня для базовой конфигурации до 2–3 дней если нужны кастомные метрики, интеграция с существующим стеком мониторинга и исторический анализ накопленных логов. Стоимость рассчитывается индивидуально в зависимости от сложности кластера и требуемого набора инструментов.
Настройка мониторинга PostgreSQL — не разовое действие, а инвестиция в стабильность. Мы гарантируем качество настройки. Закажите аудит PostgreSQL-мониторинга — получите полную картину здоровья базы. Свяжитесь с нами для консультации. Получите консультацию прямо сейчас.
