Мониторинг производительности БД: pg_stat_statements и slow query log

Представьте: ваш интернет-магазин нагружает базу, через каждые 5 минут страницы грузятся по 10 секунд, а в пик продаж сайт ложится. Вы проверяете сервер — CPU свободен, памяти запас, а запросы всё равно медленные. Без мониторинга производительности БД вы ищете проблему вслепую. Мы настраиваем pg_stat_statements и slow query log, подключаем Prometheus с Grafana — и вы видите точные метрики: cache hit rate, лаг репликации, самые тяжёлые запросы. За 2 дня вы получаете дашборды, которые в реальном времени показывают, какие запросы тормозят систему. Это не разовая проверка — это постоянный контроль.

Мы уже сталкивались с ситуацией, когда один медленный JOIN из-за неправильного индекса съедал 40% времени базы. После настройки мониторинга клиент нашёл и исправил проблему за час. Экономия на операционных расходах достигает 30% за счёт снижения простоев. Оценим ваш проект бесплатно — напишите нам.

Как pg_stat_statements помогает выявить медленные запросы?

Расширение pg_stat_statements накапливает статистику по каждому уникальному запросу: время выполнения, количество вызовов, стандартное отклонение. Конфигурация минимальна:

shared_preload_libraries = 'pg_stat_statements' pg_stat_statements.max = 10000 pg_stat_statements.track = all pg_stat_statements.track_utility = off 

После перезапуска создайте расширение и выполните запрос для поиска проблем:

-- Топ по суммарному времени SELECT left(query, 120) AS query, calls, round(total_exec_time::numeric / 1000, 1) AS total_sec, round(mean_exec_time::numeric, 1) AS avg_ms, round(stddev_exec_time::numeric, 1) AS stddev_ms, round(rows::numeric / nullif(calls, 0), 0) AS rows_per_call FROM pg_stat_statements WHERE dbid = (SELECT oid FROM pg_database WHERE datname = current_database()) AND calls > 10 ORDER BY total_exec_time DESC LIMIT 20; -- Запросы с большим разбросом времени SELECT left(query, 120) AS query, calls, round(mean_exec_time::numeric, 1) AS avg_ms, round(stddev_exec_time::numeric, 1) AS stddev_ms, round(stddev_exec_time / nullif(mean_exec_time, 0) * 100, 1) AS cv_pct FROM pg_stat_statements WHERE calls > 100 ORDER BY cv_pct DESC LIMIT 10; 

На одном проекте мы обнаружили запрос, который выполнялся в среднем 2,3 секунды и занимал 15% от общего времени БД. После добавления индекса время упало до 15 мс — ускорение в 153 раза. pg_stat_statements documentation подтверждает, что это самый быстрый способ получить агрегированную картину. В сравнении со slow query log:

Вместе они в 3 раза быстрее помогают локализовать узкое место, чем ручной просмотр логов.

Почему slow query log важен для MySQL?

В MySQL включаем slow query log с порогом 1 секунда и логированием запросов без индексов:

slow_query_log = ON slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1 log_queries_not_using_indexes = ON min_examined_row_limit = 1000 log_slow_rate_limit = 100 

Типичный случай: запрос без индекса сканировал 500 000 строк, выполняясь 4,2 секунды. После анализа мы добавили составной индекс, и время сократилось до 0,03 секунды — снижение на 99,3%. Анализируем через Percona Toolkit:

pt-query-digest --since="1h ago" --limit 20 --output report /var/log/mysql/slow.log 

Это даёт count, avg/max time и rows examined для каждого уникального запроса.

Метрический мониторинг: Prometheus + Grafana

Для PostgreSQL используем postgres_exporter, для MySQL — mysqld_exporter. Конфигурация экспортёров стандартная, настраивается за час. Ключевые метрики и алерты:

Пример правил алертинга:

groups: - name: postgresql rules: - alert: PostgreSQLSlowQueries expr: rate(pg_stat_statements_total_exec_time_seconds_total[5m]) > 10 for: 2m - alert: PostgreSQLHighConnections expr: pg_stat_activity_count > pg_settings_max_connections * 0.8 

Вы можете импортировать готовые дашборды Grafana (ID 9628 для PostgreSQL, 7362 для MySQL).

Что входит в работу по настройке мониторинга БД?

Мы предоставляем полный комплект документации: описание конфигурации доступов, инструкции по развертыванию, руководство по действиям при срабатывании алертов. После внедрения вы получаете:

• Настроенные экспортёры для PostgreSQL и MySQL.
• Дашборды Grafana с ключевыми метриками (cache hit rate, лаг репликации, топ запросов).
• Кастомные алерты с отправкой в Telegram или Slack.
• Обучение команды: как интерпретировать метрики и реагировать на алерты.
• Ежедневные отчёты pgBadger по медленным запросам.

Это позволяет вашей команде самостоятельно поддерживать производительность БД без внешней помощи. Стоимость внедрения окупается за 2 месяца за счёт сокращения простоев. Получите консультацию — мы оценим ваш проект за 1 час.

Какие этапы включает настройка мониторинга БД?

1. Аналитика: сбор текущих метрик, выявление узких мест по логам и статистике.
2. Настройка pg_stat_statements и slow_query_log с оптимальными параметрами.
3. Деплой Prometheus экспортёров (postgres_exporter, mysqld_exporter).
4. Создание кастомных дашбордов Grafana с ключевыми метриками cache hit rate, лага репликации, топ запросов.
5. Настройка алертов в Alertmanager с отправкой в Telegram/Slack.
6. Интеграция pgBadger для ежедневных отчётов и обучение команды.
7. Документация по конфигурации и действиям при срабатывании алертов.

Какие типичные ошибки допускают при настройке мониторинга БД?

• Не включают pg_stat_statements.track_utility = off — замусоривают статистику служебными запросами.
• Забывают настроить log_line_prefix для MySQL — теряют контекст в slow log.
• Используют один дашборд для всех баз — игнорируют специфику репликации и шардинга.
• Не устанавливают порог alertmanager на burst — получают спам при кратковременных всплесках.

Мы исправляем эти ошибки на этапе внедрения. Наши инженеры имеют 5+ лет опыта в администрировании PostgreSQL и MySQL, сертифицированы по Prometheus. Более 10 проектов по оптимизации производительности БД гарантируют результат. После внедрения мониторинга клиенты экономят до 40% времени на диагностику и сокращают простои в 2 раза. Закажите настройку мониторинга БД — и мы выявим узкие места за 2 дня.