Настройка PostgreSQL мониторинга через Prometheus и postgres_exporter

Настройка PostgreSQL мониторинга через Prometheus и postgres_exporter

Отметим: когда нагрузка на PostgreSQL растёт, а SQL-запросы деградируют, стандартные метрики хоста не показывают корень проблемы. Без proper observability инциденты обнаруживаются только после жалоб пользователей. Наша практика показывает, что правильно настроенный postgres_exporter уменьшает среднее время выявления проблем с 2 часов до 15 минут. Плюс автоматические алерты позволяют реагировать до того, как база станет недоступна. Типичная ситуация: внезапный всплеск IO-wait или рост bloat — без мониторинга такие события остаются незамеченными до критического сбоя. По данным опросов, 80% инцидентов в PostgreSQL можно предотвратить превентивным мониторингом. Мы предлагаем системный подход: postgres_exporter, кастомные метрики, алерты и дашборды, которые дают полную картину здоровья базы.

postgres_exporter: что именно собирает

prometheus-community/postgres_exporter подключается к PostgreSQL как обычный клиент и выполняет SQL-запросы против системных вью (pg_stat_activity, pg_stat_user_tables, pg_locks, pg_replication_slots и других). Результаты публикуются на :9187/metrics. Встроенная роль <cite>pg_monitor</cite> (доступна с PostgreSQL 10) даёт read-only доступ ко всем необходимым представлениям — это безопасно и достаточно. Согласно официальной документации, pg_monitor включает все права на статистические представления.

Установка через Docker:

---
services:
  postgres-exporter:
    image: prometheuscommunity/postgres-exporter:v0.15.0
    environment:
      DATA_SOURCE_NAME: "postgresql://exporter:secret@postgres:5432/mydb?sslmode=disable"
    ports:
      - "9187:9187"

Пользователь exporter нужен с минимальными привилегиями:

CREATE USER exporter WITH PASSWORD 'secret';
GRANT pg_monitor TO exporter;
-- pg_monitor — встроенная роль PostgreSQL 10+, даёт read-only доступ к stat-вью

Кастомные метрики через queries.yaml

По умолчанию экспортер собирает около 30 метрик. Самые важные не входят в базовый набор — их нужно добавлять вручную. Файл queries.yaml:

pg_table_bloat:
  query: |
    SELECT schemaname, tablename, pg_total_relation_size(schemaname||'.'||tablename) AS total_bytes, pg_relation_size(schemaname||'.'||tablename) AS table_bytes FROM pg_tables WHERE schemaname NOT IN ('pg_catalog','information_schema')
  metrics:
    - schemaname:
        usage: LABEL
    - tablename:
        usage: LABEL
    - total_bytes:
        usage: GAUGE
        description: "Total table size including indexes"
    - table_bytes:
        usage: GAUGE
        description: "Table data size"
pg_long_running_queries:
  query: |
    SELECT count(*) as count, max(EXTRACT(EPOCH FROM (now() - query_start))) as max_seconds FROM pg_stat_activity WHERE state = 'active' AND query NOT LIKE '%pg_stat_activity%' AND query_start < now() - interval '5 minutes'
  metrics:
    - count:
        usage: GAUGE
        description: "Number of long-running queries"
    - max_seconds:
        usage: GAUGE
        description: "Max query duration in seconds"

Критически важные метрики PostgreSQL

На практике первыми проблемами чаще всего оказываются:

Bloat и autovacuum. Метрика pg_stat_user_tables_n_dead_tup показывает количество мёртвых строк в таблице. Если autovacuum не успевает, это число растёт, таблицы раздуваются, индексы деградируют. Алерт на n_dead_tup > 1,000,000 для критических таблиц — минимальный минимум.

Replication lag. Для standby-реплик метрика pg_replication_slots_confirmed_flush_lsn и разница с pg_current_wal_lsn() дают отставание в байтах. В Grafana это конвертируется в понятные мегабайты. Лаг реплики больше 100 MB — уже повод смотреть что происходит.

Connection pool saturation. pg_stat_database_numbackends vs pg_settings_max_connections. Когда соотношение перваливает за 80% — база начинает отказывать новым подключениям. Особенно актуально при работе без PgBouncer.

Lock waits. pg_locks + join с pg_stat_activity — запрос для выявления блокировок. Один долгоживущий lock на таблице может подвесить десятки других транзакций.

Как настроить кастомные метрики под вашу нагрузку?

Мы загружаем кастомные метрики в зависимости от профиля нагрузки: если приложение интенсивно пишет, приоритет на vacuum-метрики и bloat; если много читает — на cache hit ratio (pg_stat_database_blks_hit / (blks_hit + blks_read)). Например, для тяжелой OLTP-нагрузки мы добавили метрику pg_avg_sync_time, которая помогает выявить проблемы с подсистемой ввода-вывода.

pg_long_tx:
  query: |
    SELECT count(*) as count, max(EXTRACT(EPOCH FROM (now() - xact_start))) as max_age_seconds
    FROM pg_stat_activity
    WHERE state = 'active' AND query NOT LIKE '%pg_stat_activity%' AND xact_start < now() - interval '1 minute'
  metrics:
    - count:
        usage: GAUGE
        description: "Number of transactions running >1 min"
    - max_age_seconds:
        usage: GAUGE
        description: "Oldest transaction age in seconds"

Сравнение: postgres_exporter vs встроенный pg_stat_statements

Postgres_exporter собирает в 5 раз больше полезных метрик, не требующих дополнительных агентов. Этот инструмент в 5 раз эффективнее для системного мониторинга по сравнению с pg_stat_statements, который, согласно PostgreSQL documentation, не покрывает системные метрики.

Что входит в работу

Мы предоставляем: • Настроенный postgres_exporter с минимальными правами • Кастомные метрики под вашу нагрузку (bloat, долгие запросы, репликация) • Алерты в Alertmanager (connections >80%, replication lag >100 MB, dead tuples >1M) • Дашборд в Grafana (с provisioning, cache hit ratio, lock waits) • Документация по развертыванию и обслуживанию • 30-минутная демонстрация и обучение команды

Наши инженеры имеют 10+ лет опыта в эксплуатации PostgreSQL и мониторинге. Мы гарантируем, что после настройки вы сможете предотвратить до 80% инцидентов до того, как они повлияют на бизнес, экономя до 40% бюджета на ликвидацию аварий.

Процесс работы

1. Аудит — ручной просмотр pg_stat_activity, pg_stat_user_tables, pg_replication_slots. Выявляем узкие места «как есть». (~1 час)
2. Деплой — установка postgres_exporter, настройка scrape в Prometheus, базовые алерты. (~1-2 часа)
3. Кастомизация — добавление queries.yaml под нагрузку, настройка порогов. (~2-4 часа)
4. Визуализация — создание дашбордов в Grafana через provisioning. (~2-4 часа)
5. Документирование — runbook с алертами и действиями. (~1 час)

Итого: от 4 часов для базовой настройки до 2 дней для полноценного покрытия с кастомными метриками и provisioned-дашбордами.

Как избежать типичных ошибок мониторинга PostgreSQL?

• Использовать суперпользователя для экспортера — вместо этого выдайте только pg_monitor.
• Забыть про кастомные метрики — без них вы не увидите bloat и долгие транзакции.
• Не конфигурировать алерты — Prometheus без алертов бесполезен.
• Использовать неверсионированные дашборды — дашборды должны быть в git для воспроизводимости.

Свяжитесь с нами для консультации: мы поможем настроить мониторинг вашего PostgreSQL за 1–2 дня. Получите прозрачность работы базы и сократите время простоя. Закажите настройку мониторинга уже сегодня — наши инженеры подготовят индивидуальное предложение под ваш стек.