Налаштування моніторингу 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. Вбудована роль pg_monitor (доступна з 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 дні. Отримайте прозорість роботи бази та скоротите час простою. Замовте налаштування моніторингу вже сьогодні — наші інженери підготують індивідуальну пропозицію під ваш стек.