Мониторинг PostgreSQL в Zabbix: полное руководство

Зачем нужен мониторинг PostgreSQL и что он дает

Настроенный zabbix postgresql мониторинг позволяет увидеть реальную картину работы СУБД: от числа активных подключений до глубины кэша. Без такого контроля сбои обнаруживаются постфактум, когда пользователи уже жалуются на медленные ответы. Система сама сигнализирует о перегреве пула соединений или разрастании таблиц, давая время на реакцию до критической деградации.

Практическая польза сводится к нескольким пунктам:

• своевременное выявление «медленных» запросов и блокировок;
• прогнозирование роста дискового пространства;
• отслеживание эффективности работы буферного кэша;
• быстрое определение аномалий в репликации.

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

Какие метрики PostgreSQL критичны для стабильной работы

Стабильность кластера баз данных определяется не только аппаратными ресурсами, но и внутренними процессами. В первую очередь стоит следить за количеством активных подключений — приближение к лимиту max_connections ведёт к отказам. Также важны:

• Cache hit ratio — доля обращений к буферному кэшу (целевое значение выше 95%).
• Время выполнения запросов и наличие долгих транзакций.
• Размер WAL-файлов и частота контрольных точек.
• Уровень автовакуума — отставание от таблиц грозит раздуванием и деградацией.

Отдельно отслеживают репликацию: задержка между ведущим и ведомыми узлами не должна превышать нескольких секунд, иначе возрастает риск потери данных.

Типичные проблемы БД, которые выявляет Zabbix

Система мониторинга способна замечать отклонения в работе PostgreSQL задолго до того, как они станут критичными. Чаще всего фиксируются:

• рост числа медленных запросов и блокировок;
• деградация кэша и падение hit ratio;
• переполнение дискового пространства или WAL-файлов;
• скачки числа подключений к серверу БД.

Эти сигналы позволяют администратору вмешаться до того, как производительность приложения заметно упадёт.

Подготовка PostgreSQL к мониторингу в Zabbix

Прежде чем система начнет собирать метрики, серверу БД нужно разрешить внешнее подключение. Создайте отдельную учетную запись с правами только на чтение — так вы не дадите мониторинговому скрипту лишних привилегий. Понадобится и правка конфигурационного файла pg_hba.conf, где указывается адрес Zabbix-сервера. Убедитесь, что в postgresql.conf параметр listen_addresses не ограничивает доступ только локальной петлей.

Создание пользователя и прав доступа для Zabbix-агента

Для корректного снятия метрик с кластера потребуется отдельная учётная запись. Создайте роль с минимально необходимыми привилегиями — это снизит риски при компрометации.

• Логин: zbx_monitor (пароль задайте надёжный, например, через pgcrypto);
• Выдайте права на чтение представлений pg_stat_* и pg_stat_replication;
• Для версий 14+ дополнительно разрешите выполнение функций pg_wal_lsn_diff.

Гранты удобно выдать одной командой:

GRANT CONNECT ON DATABASE postgres TO zbx_monitor;
GRANT pg_monitor TO zbx_monitor;

Роль pg_monitor уже включает доступ к большинству системных представлений, поэтому отдельные разрешения обычно не нужны.

Настройка pg_hba.conf и параметров подключения

Для корректного доступа сервера Zabbix к кластеру PostgreSQL необходимо отредактировать файл аутентификации. В секции для нужной базы данных и пользователя укажите метод md5 или scram-sha-256, а также адрес хоста, с которого выполняется подключение. После изменений перезагрузите конфигурацию командой SELECT pg_reload_conf();.

Проверьте параметры в postgresql.conf: listen_addresses должен включать нужный интерфейс, а port — соответствовать значению в настройках Zabbix. Для диагностики используйте psql -h -U -d .

Установка и настройка шаблона Zabbix для PostgreSQL

Для развертывания контроля над кластером СУБД в Zabbix 6.0 и новее используется штатный шаблон PostgreSQL by Zabbix agent 2. Он доступен в каталоге шаблонов сразу после установки сервера. Вам потребуется лишь добавить хост с агентом и привязать к нему этот пресет.

Порядок действий выглядит так:

1. Убедитесь, что на сервере БД установлен и запущен Zabbix agent 2 (пакет zabbix-agent2).
2. В веб-интерфейсе Zabbix перейдите в раздел Data collection → Hosts и создайте новый хост, указав IP или DNS-имя сервера PostgreSQL.
3. В поле Templates начните вводить «PostgreSQL by Zabbix agent 2» и выберите нужный шаблон из выпадающего списка.
4. Задайте имя пользователя и пароль для подключения к БД в макросах шаблона: {$PG.USER} и {$PG.PASSWORD}.
5. Дождитесь появления данных в разделе Latest data — обычно это занимает не более минуты.

Если подключение не проходит, проверьте файл pg_hba.conf — в нём должна быть разрешена аутентификация с хоста, где работает агент. Для локального подключения часто достаточно строки local all zabbix md5.

Где скачать официальный шаблон и скрипты для PostgreSQL

Официальные средства контроля опубликованы в репозитории Zabbix на GitHub. В каталоге templates/db/postgresql лежит шаблон, а в templates/db/postgresql/scripts — вспомогательные утилиты. Для работы потребуется агент 5.0 или новее. Актуальные версии всегда доступны на странице релизов проекта.

Импорт шаблона и подключение хоста БД в Zabbix

После установки агента на сервер с PostgreSQL переходим к настройке фронтенда. В веб-интерфейсе Zabbix зайдите в раздел «Data collection» → «Templates» и нажмите кнопку «Import». Укажите путь к файлу шаблона template_db_postgresql.yaml, который поставляется вместе с официальным репозиторием. Убедитесь, что в параметрах импорта отмечены пункты «Templates» и «Value mappings».

Далее создайте хост для вашей базы данных:

• Перейдите в «Data collection» → «Hosts» → «Create host».
• В поле «Host name» укажите понятное имя, например, pg-prod-01.
• В поле «Interfaces» добавьте агентский интерфейс с IP-адресом вашего сервера БД.
• На вкладке «Templates» прикрепите импортированный шаблон.
• В макросах задайте параметры подключения: {$PG.USER} и {$PG.PASSWORD}.

После сохранения хоста подождите пару минут — данные появятся в разделах «Latest data» и «Monitoring» → «Hosts». Если статус агента показывает «ZBX» красным, проверьте доступность порта 10050 и корректность настроек в конфигурационном файле агента.

Настройка Zabbix Agent для сбора метрик PostgreSQL

Для начала работы потребуется установить пакет, отвечающий за связку агента с СУБД. В большинстве дистрибутивов он называется zabbix-agent2 и включает специальный плагин для работы с PostgreSQL. После установки в конфигурационном файле агента (обычно /etc/zabbix/zabbix_agent2.conf) нужно указать параметры подключения к базе: хост, порт и имя пользователя.

Убедитесь, что у учётной записи, под которой агент будет ходить в базу, есть права на чтение системных представлений. Обычно достаточно выдать роль pg_monitor. Проверить работоспособность можно командой:

zabbix_agent2 -t postgresql.ping

Если ответ возвращает 1 — соединение установлено. Далее останется только импортировать готовый шаблон в веб-интерфейсе и привязать его к нужному хосту.

Конфигурация UserParameter для запросов к PostgreSQL

Чтобы Zabbix мог выполнять произвольные SQL-запросы, в файле конфигурации агента (обычно zabbix_agentd.conf или каталог zabbix_agentd.d/) прописывают пользовательские параметры. Синтаксис прост: UserParameter=ключ.имя, команда. Для работы с базой удобно использовать утилиту psql с переменными окружения, чтобы не хранить пароль в открытом виде.

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

UserParameter=pg.connections,psql -h localhost -U zabbix -d postgres -tAc "SELECT count(*) FROM pg_stat_activity;"

После правки конфигурации обязательно перезапустите агента. Проверить работоспособность можно командой zabbix_get -s 127.0.0.1 -k pg.connections. Если возвращается число — всё в порядке. Для сложных выборок создавайте отдельные SQL-файлы и вызывайте их через psql -f, это упрощает отладку и сопровождение.

Проверка доступности метрик через zabbix_get

Утилита zabbix_get — это быстрый способ убедиться, что сервер опрашивает нужные параметры без задержек. Команда выполняется на стороне Zabbix-сервера или прокси:

zabbix_get -s 192.168.1.50 -k pg.ping

В ответе ожидается 1. Если возвращается пустая строка или ошибка — проверьте права пользователя в pg_hba.conf и корректность имени хоста в макросе. Для диагностики конкретных метрик вроде числа активных соединений подставьте соответствующий ключ из шаблона.

Ключевые метрики PostgreSQL в Zabbix: разбор и настройка

При наблюдении за кластером баз данных важно отслеживать не только загрузку CPU, но и внутренние счетчики. Система мониторинга позволяет снимать показатели числа одновременных подключений, объем кэша, частоту контрольных точек и время выполнения запросов. Эти данные помогают выявить деградацию производительности до того, как она станет критичной.

Для сбора используется официальный шаблон, который опирается на SQL-запросы к статистическим представлениям. Настройка сводится к указанию учетной записи с правами чтения и корректировке интервалов опроса. Ниже приведены базовые параметры для контроля.

Группа	Что измеряет	Типичная проблема
Активность	Число транзакций в секунду, доля блокировок	Рост очередей ожидания
Память	Попадания в буферный кэш, использование shared_buffers	Нехватка выделенной памяти
Репликация	Задержка между ведущим и ведомыми узлами	Расхождение данных

Обратите внимание: часть метрик требует включения расширения pg_stat_statements. Без него невозможно получить данные о времени выполнения отдельных запросов, что существенно сужает диагностические возможности.

Мониторинг активности соединений и числа транзакций

Наблюдение за подключениями к кластеру и интенсивностью операций — базовая часть контроля СУБД. В Zabbix для этого применяются элементы данных, получаемые через SQL-запросы к представлениям pg_stat_activity и pg_stat_database. Отслеживание числа активных сессий помогает вовремя заметить утечки или аномальный всплеск нагрузки. Количество транзакций в секунду (TPS) вычисляется по разнице счётчиков xact_commit и xact_rollback за интервал опроса. Для удобства можно настроить триггеры на превышение пороговых значений, например, при заполнении пула соединений более чем на 90%.

Отслеживание кэша, буферов и производительности запросов

Для оценки эффективности работы СУБД важно контролировать попадания в общий кэш. Низкий показатель cache hit ratio (ниже 95%) сигнализирует о нехватке выделенной памяти под совместно используемые буферы. В этом случае стоит пересмотреть параметр shared_buffers в конфигурации.

Отдельного внимания заслуживает скорость выполнения выборок. Медленные запросы выявляются через анализ логов или статистики pg_stat_statements. Обращайте внимание на рост числа сканирований таблиц — это часто указывает на отсутствие подходящих индексов.

Полезно отслеживать и число одновременных подключений к базе, чтобы вовремя заметить исчерпание пула соединений.

Создание триггеров и алертов для PostgreSQL в Zabbix

Когда метрики собраны, пора настроить оповещения. Без них мониторинг теряет смысл — вы узнаете о проблеме последним. Логика проста: задаёте пороговое значение, и система реагирует, когда оно превышено.

Для начала определитесь, что для вас критично. Например, рост числа заблокированных транзакций или падение количества кэш-хитов. Под каждую ситуацию создаётся отдельное правило.

• Выберите элемент данных, на который будете опираться.
• Укажите выражение — условие срабатывания.
• Задайте уровень серьёзности: от информации до катастрофы.
• Назначьте действие — отправку уведомления или запуск скрипта.

Удобно группировать триггеры по смыслу. Например, отдельно для дискового пространства, отдельно для репликации. Так проще управлять уведомлениями и не тонуть в шуме.

Не забывайте про гистерезис — возврат в нормальное состояние не должен мгновенно гасить алерт. Иначе при флуктуациях значений вы получите шторм сообщений.

Настройка порогов срабатывания на критические значения

Определение граничных величин для алертов — задача, требующая аккуратности. Слишком низкий предел вызовет шквал ложных уведомлений, завышенный — пропустит реальную деградацию. Рекомендуется отталкиваться от базовой производительности системы в спокойный период и добавлять запас 20–30%.

• Для загрузки CPU и памяти удобно использовать триггеры с функцией last() и сравнением за несколько последовательных проверок.
• Время ответа на запрос лучше контролировать процентилями (например, p95), чтобы отсечь случайные всплески.
• Число активных соединений стоит привязать к лимиту max_connections из конфигурации PostgreSQL.

Полезно настраивать разные уровни серьезности: предупреждение — при кратковременном отклонении, высокая серьезность — при устойчивой проблеме в течение 5–10 минут. Такой подход снижает усталость оператора от оповещений и позволяет быстрее реагировать на действительно критические ситуации.

Организация уведомлений о сбоях и деградации БД

Оповещения настраиваются через триггеры. Для критичных инцидентов (недоступность сервиса, повреждение страниц) задают уровень Disaster, для предвестников проблем (рост времени выполнения запросов, переполнение WAL) — Warning. Каналы доставки: Telegram, Slack, email. Чтобы избежать шумовых алертов, применяют гистерезис и зависимые триггеры, которые блокируют срабатывание при плановых работах.

Визуализация данных и дашборды для PostgreSQL

Собранные метрики превращаются в наглядные графики через штатные средства Zabbix. Для быстрого анализа удобно группировать виджеты на отдельных страницах: например, один экран под нагрузку CPU и дисков, другой — под активность сессий и блокировки. Полезно добавить карту производительности, где цветом подсвечиваются узлы кластера. Такой подход позволяет оперативно замечать аномалии, не углубляясь в сырые цифры.

Сборка информативного дашборда по ключевым метрикам БД

Для быстрой оценки состояния кластера удобно вывести на один экран несколько виджетов. В качестве основы берутся данные о числе активных подключений, объёме кэша и времени выполнения запросов. Полезно добавить график утилизации дискового пространства и индикатор долгих транзакций. Такой набор позволяет оперативно замечать аномалии, не углубляясь в логи. При необходимости панель дополняется показателями репликации и частоты контрольных точек.

Графики и макросы для быстрого анализа состояния PostgreSQL

Визуализация данных в Zabbix строится на предопределённых элементах и пользовательских выражениях. Для быстрой оценки состояния СУБД удобно использовать готовые шаблоны с графиками по ключевым метрикам: число активных подключений, объём транзакций, время выполнения запросов. Макросы позволяют гибко настраивать пороги срабатывания триггеров без правки самих элементов. Например, переменная {$PG.HOST} задаёт адрес инстанса, а {$PG.PORT} — порт подключения. Это упрощает переиспользование одного шаблона для разных серверов.