Введение
pg_exporter — это продвинутый Prometheus-exporter для мониторинга PostgreSQL и pgBouncer, который делает упор на «настраиваемость как продукт»: декларативный YAML-конфиг, динамическое планирование (replanning) и кастомные коллекторы. По задумке он закрывает практически весь стандартный набор задач наблюдаемости PostgreSQL: из коробки доступно 600+ метрик и около 3K time series на один инстанс.
Официальный репозиторий: https://github.com/pgsty/pg_exporter
1) Что такое pg_exporter и зачем он нужен
В классической схеме мониторинга PostgreSQL вы строите цепочку:
- PostgreSQL / pgBouncer → exporter (метрики) → Prometheus (сбор) → Grafana (дашборды) → Alertmanager (алерты)
Экспортер в этой цепочке — «переводчик» состояния базы в формат метрик Prometheus. pg_exporter отличается тем, что делает этот перевод максимально управляемым через конфигурацию: вы описываете метрики и правила их сбора декларативно, а не «принимаете как есть» фиксированный набор.
2) Ключевые возможности pg_exporter
2.1 Декларативный конфиг (YAML)
Вместо того чтобы жить в рамках жёстко заданных метрик, вы управляете сбором через YAML: какие коллекторы включены, какие запросы выполняются, какие лейблы формируются и как интерпретируются результаты.
2.2 Кастомные коллекторы и расширение метрик
Если вам не хватает метрик под ваш сценарий (например, под конкретное расширение, workload или внутренние требования SRE), вы добавляете их в конфиг — без форка и без пересборки.
2.3 Динамическое планирование (replanning)
Сбор метрик может адаптироваться к контексту: версии PostgreSQL, роли узла (primary/replica), доступности представлений, наличию расширений и т.д. Это полезно, когда у вас «зоопарк» инстансов и нужно единообразие мониторинга без ручной матрицы исключений.
2.4 Hot reload (обновления без остановки)
На практике это означает, что вы можете менять конфигурацию (например, добавлять метрики или корректировать таймауты) без длительных простоев и без «рваного» мониторинга.
3) Что именно можно мониторить
pg_exporter ориентирован на то, чтобы покрыть основные домены наблюдаемости PostgreSQL. Обычно сюда входят:
- Нагрузка и активность: коннекты, транзакции, активные запросы, throughput.
- Задержки и «симптомы» деградации: рост времени выполнения, очереди ожиданий.
- Locks и конкуренция: блокировки, contention и ожидания.
- I/O и кэш: буферы, чтения/записи, давление на подсистемы хранения.
- WAL и чекпоинты: темпы генерации WAL, поведение checkpoint, признаки проблем с записью.
- Vacuum / autovacuum: активность, задержки, индикаторы накопления «мусора».
- Репликация: лаг, состояние потоковой репликации (при наличии соответствующих collector’ов).
- pgBouncer: пулы, состояния, очереди, соединения и их распределение.
Важно: финальный набор зависит от того, какие коллекторы включены и как настроена конфигурация.
4) Как устроен сбор метрик в pg_exporter
В упрощённом виде логика выглядит так:
- Exporter подключается к PostgreSQL/pgBouncer по DSN (строке подключения).
- Выполняет SQL-запросы, описанные в YAML (плюс проверки/условия выполнения).
- Преобразует результаты запросов в метрики Prometheus (counters, gauges, histograms — в зависимости от описания).
- Отдаёт всё по HTTP endpoint’у, который опрашивает Prometheus.
5) Быстрый старт: минимальные шаги
Ниже — базовая логика запуска, без привязки к конкретному способу установки (контейнер/пакет/бинарник), потому что в проде это всегда завязано на ваше окружение.
5.1 Создайте роль для мониторинга
Рекомендуется заводить отдельную роль (read-only) и выдавать только необходимые права на системные представления и функции, которые будут использоваться вашими коллекторами.
5.2 Опишите подключения (DSN)
Как правило, DSN передают через переменные окружения или конфиг. Пример формата строки подключения:
postgresql://monitor_user:password@127.0.0.1:5432/postgres?sslmode=disable5.3 Запустите pg_exporter и проверьте endpoint
После запуска у exporter’а появится HTTP endpoint метрик (обычно /metrics). Проверка типовая:
- Endpoint доступен по сети (Prometheus его видит).
- Метрики отдаются без ошибок.
- Нагрузка от exporter’а не вызывает заметной деградации.
5.4 Подключите Prometheus
В Prometheus добавляется scrape job на exporter:
scrape_configs: - job_name: "pg_exporter" static_configs: - targets: ["exporter-host:port"]Как быстро развернуть pg_exporter в облаке Serverspace.uz
Если вы хотите собрать мониторинг PostgreSQL без лишней возни с инфраструктурой, проще всего поднять pg_exporter рядом с базой в облаке. В Serverspace.uz можно быстро развернуть облачный сервер под PostgreSQL/pgBouncer и мониторинг, а дальше спокойно подключить Prometheus и Grafana — без привязки к «железу» и ручного администрирования на каждом шаге.
Плюс такого подхода в том, что вы сохраняете контроль: мониторинг живёт в вашей инфраструктуре, а конфиги pg_exporter (YAML) можно версионировать и обновлять под новые метрики и задачи. Если нагрузка растёт — ресурсы сервера масштабируются без миграций и простоев, а сама схема мониторинга остаётся прежней.
Посмотреть облачные серверы: https://serverspace.uz/services/cloud-servers/
6) Конфигурация YAML: как мыслить правильно
Чтобы конфиг был удобен, полезно думать не «по метрикам», а «по профилям сбора».
6.1 Разделяйте быстрые и дорогие метрики
Некоторые запросы лёгкие и можно собирать часто (каждые 5–15 секунд). Другие — тяжёлые и лучше собирать реже или через кэширование. Правильный подход:
- Частые метрики: активность, коннекты, базовые counters.
- Редкие метрики: bloat-индикаторы, глубокая статистика по таблицам/индексам, «тяжёлые» агрегации.
6.2 Используйте таймауты и кэширование
Смысл простой: мониторинг не должен превращаться в нагрузочный тест.
- Таймауты защищают от зависания запросов и «запирания» exporter’а.
- Кэширование сглаживает пики и снижает количество одинаковых запросов.
6.3 Условия выполнения (conditions)
В реальных инфраструктурах узлы разные:
- Разные версии PostgreSQL
- Primary и Replica
- Разный набор расширений
Условность помогает сделать один «универсальный» конфиг, который корректно отрабатывает на всех инстансах, пропуская нерелевантные коллекторы.
7) Пример структуры коллектора (шаблон)
Ниже — упрощённый пример, чтобы понимать логику. Это не «готовый конфиг под копипаст», а иллюстрация подхода.
collectors:
name: pg_stat_database
enabled: true
timeout: 500ms
cache: 5s
when:
pg_version: ">= 10"
metrics:
name: pg_db_xact_commit_total
help: "Committed transactions per database"
type: counter
sql: |
SELECT datname, xact_commit
FROM pg_stat_database;
labels: [datname]
value: xact_commit
Что важно:
- timeout и cache — инструменты контроля нагрузки.
- when — правила применимости коллектора.
- sql — запрос, который должен быть стабильным и безопасным по времени.
- labels — ключевые измерения (например, база, схема, таблица), которые могут сильно увеличить кардинальность.
8) Кардинальность и time series: где можно «перестрочить» Prometheus
Заявленные «~3K time series на инстанс» — это ориентир, но итог зависит от того, как вы используете лейблы. Типичные ошибки:
- Добавить лейбл с очень большим количеством значений (например, query_id/statement).
- Собирать метрики по всем таблицам/индексам во всех базах слишком часто.
- Включить «диагностические» метрики как продовые и не ограничить частоту.
Практический вывод: сначала включайте базовый профиль, затем расширяйте метрики постепенно, оценивая рост кардинальности и стоимость хранения.
9) Практические сценарии использования
9.1 Единый мониторинг для разных версий PostgreSQL
Если у вас есть и старые, и новые инстансы, условные правила и динамическое планирование помогают держать единый конфиг без разветвления по веткам.
9.2 Мониторинг pgBouncer как часть наблюдаемости базы
Если pgBouncer участвует в архитектуре, его метрики часто дают ответ быстрее, чем сама база:
- очереди и лимиты пулов
- доля ожиданий соединений
- перекос по пулам
9.3 Добавление «своих» метрик
Например:
- метрики по конкретным расширениям
- контроль SLA на уровне прикладных таблиц
- индикаторы, которые важны именно вашему продукту
10) Чек-лист продовой эксплуатации
- Отдельная мониторинговая роль и минимально необходимые права.
- Таймауты для запросов и защита от «зависаний».
- Кэширование там, где метрики не должны быть «помесячно точными до миллисекунды».
- Контроль кардинальности (лейблы и частота).
- Разделение профилей: быстрые/дорогие метрики.
- Тест на нагрузку: посмотрите влияние exporter’а на CPU/I/O и latency.
FAQ
Чем pg_exporter лучше «обычного» postgres_exporter?
Основное отличие — декларативная и расширяемая модель метрик: конфигом вы управляете тем, что собирается и как, а не ограничиваетесь фиксированным набором. Плюс hot reload и динамическое планирование упрощают поддержку разношёрстной инфраструктуры.
Можно ли использовать pg_exporter только для pgBouncer?
Да, если у вас именно такая задача. Важно корректно настроить DSN и включить нужные collectors.
Насколько «тяжёлым» будет мониторинг?
Это определяется конфигом: частотой scrape, количеством коллекторов, сложностью SQL и выбранными лейблами. Нормальная практика — начинать с базового набора и расширять постепенно.
Какие типичные ошибки при настройке?
Чаще всего — отсутствие таймаутов, включение дорогих метрик на высокой частоте и избыточные лейблы, которые резко увеличивают число time series.
Вывод
pg_exporter — хороший выбор, когда вам нужен не просто «набор стандартных метрик», а управляемая observability-платформа вокруг PostgreSQL и pgBouncer. Сильные стороны — YAML-конфигурация, кастомные коллекторы, replanning и hot reload, а также масштабируемость под реальные инфраструктуры, где версии и роли узлов отличаются. Начните с базового профиля, контролируйте кардинальность и стоимость запросов — и вы получите предсказуемый мониторинг без лишней нагрузки на базу.
