Мониторинг репликации PostgreSQL в Zabbix

Опубликовано: 09.05.2019

Настройку мониторинга выполним в 5 шагов:

Подготовка сервера СУБД. Нам нужны учетные записи postgresql для выполнения запросов на получение статистики.
Написание скрипта, который будет анализировать состояние репликации в PostgreSQL. Если репликация работает без сбоя, то скрипт будет возвращать 0, если есть проблема — 1.
Настройка Zabbix агента для запуска скрипта при отправке соответствующего запроса от сервера. Добавим UserParameter в конфигурационный файл zabbix-agentd.conf.
Настройка Zabbix сервера для мониторинга репликации сервера баз данных. Импортируем шаблон с настройками тригера и параметров отправки запроса на получение состояния от агента. Также на данном этапе привяжем шаблон к хосту.
Проверка настроек. Отключаем репликацию и наблюдаем за реакцией Zabbix.

1. Создание пользователей

Для мониторинга состояния репликации, необходимо обращаться к служебным таблицам. Чтобы не делать этого от системной учетной записи postgres, создаем новую.

На Master

На мастере создаем нового пользователя командой:

sudo -u postgres createuser -P mon_replication

* в данном примере мы создадим пользователя mon_replication
* после ввода команды система потребует ввести новый пароль. Задаем более сложный, например, repl_password3.

Открываем конфигурационный файл pg_hba.conf. Для этого сначала смотрим путь расположения конфигурационных файлов:

ps aux | grep postgres | grep -- -D

В полученном ответе мы увидим в конце строки что-то на подобие:

... -D /var/lib/pgsql/9.6/data/

* это и есть путь, в котором находятся конфигурационные файлы.

Открываем pg_hba.conf:

vi /var/lib/pgsql/9.6/data/pg_hba.conf

Добавляем строку:

host template1 mon_replication 127.0.0.1/32 md5

* данная строка должна быть выше строки host all all 127.0.0.1/32 ident

Перезапускаем postgresql:

systemctl restart postgresql-9.6

* в данном примере перезапускается postgre версии 9.6. Для других версий команда должна быть своей.

На Slave

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

sudo -u postgres psql -c "SELECT * FROM pg_user;"

После нам нужно внести настройки в конфигурационном файле pg_hba.conf:

vi /var/lib/pgsql/9.6/data/pg_hba.conf

* обратите внимание, что путь до /var/lib/pgsql/9.6/data на разных серверах может быть другой.

Добавляем строку:

host template1 mon_replication 192.168.1.10/32 md5

* где вместо 192.168.1.10 должен быть адрес мастер-сервера.

Перезапускаем postgresql:

systemctl restart postgresql-9.6

Снова на мастере

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

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

export PGPASSWORD='repl_password3'

* в данном примере мы создали пользователя с паролем repl_password3. Данная команда создаст системную переменную PGPASSWORD — ее значение принимает в качестве пароля сервер PostgreSQL.

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

psql -Umon_replication template1 -h127.0.0.1 -c "SELECT pg_current_xlog_location();"

* где mon_replication — созданный нами пользователь; 127.0.0.1 — сервер, к которому мы подключаемся, то есть, к самому себе.

Мы должны получить ответ, на подобие:

pg_current_xlog_location
--------------------------
0/30694B8
(1 строка)

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

psql -Umon_replication template1 -h192.168.1.11 -c "SELECT pg_last_xlog_replay_location();"

* где 192.168.1.11 — IP-адрес нашего сервера slave.

Мы должны получить ответ, похожий на ответ от мастера.

2. Скрипт для получения состояния репликации

Суть проверки сводится к выполнению двух запросов — на мастере pg_current_xlog_location, на слейве pg_last_xlog_replay_location. В ответ мы получаем отправленные запросы с master (current) и обработанные запросы сервером slave (replay). Полученные ответы имеют вид 0/304E310, где нужное нам значение идет после / — то есть, в данном примере, 304E310. Данное значение хранится в шестнадцатеричной системе счисления, чтобы получить привычное представление данных, мы будем его переводить в десятичную систему. Полученные результаты мы будем сравнивать для pg_current_xlog_location и pg_last_xlog_replay_location — их разница показывает отставание реплики и должна либо равняться нулю, либо отличаться на небольшое число.

Устанавливаем bc.

а) если используем Red Hat / CentOS / Fedora:

yum install bc

а) если используем Ubuntu / Debian:

apt-get install bc

* программа bc выполняем вычисления. В нашем случае, преобразует строку в число.

Создаем сам файл скрипта:

vi /etc/zabbix/zabbix_agentd.d/repl_pg_mon.sh

* путь до скрипта repl_pg_mon.sh может быть любой. В данном примере мы разместили его в каталог агента заббикс — во-первых, для порядка, во-вторых, не будет проблем с SELinux (если он используется).

Содержимое скрипта:

#!/bin/bash
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

export PGPASSWORD='repl_password3'

master_status=`psql -Umon_replication template1 -h127.0.0.1 -c "SELECT pg_current_xlog_location();" | grep '/' | awk -F "/" {'print $2'}`
master_queue=`echo "ibase=16; $master_status" | bc`

slave_status=`psql -Umon_replication template1 -h192.168.1.11 -c "SELECT pg_last_xlog_replay_location();" | grep '/' | awk -F "/" {'print $2'}`
slave_queue=`echo "ibase=16; $slave_status" | bc`

export PGPASSWORD=''

let replication_queue=$master_queue-$slave_queue

if [ $replication_queue -gt 1 ]
then
echo "0"
exit 0
fi

echo "1"
exit 0

* в данном скрипте мы подключаемся к базе мастер и получаем позицию репликации последней отправки данных на слейв, затем к базе вторичного сервера и получаем позицию репликации последнего получения данных; после — мы парсим значения двух параметров и преобразовываем шестнадцатеричное их значение в десятичное. Если разница этих значений больше 1, скрипт вернет 0, иначе — 1. В Zabbix мы будем проверять значение и реагировать на значение 0. Разница значений на 1 — очень чувствительный показатель и для больших баз, которые активно используются, слишком мал — его нужно вычислить экспериментально.

Устанавливаем права на скрипт — разрешаем запуск на выполнение и задаем владельца zabbix:

chmod 770 /etc/zabbix/zabbix_agentd.d/repl_pg_mon.sh

chown zabbix:zabbix /etc/zabbix/zabbix_agentd.d/repl_pg_mon.sh

Можно проверить работу скрипта, запустив его:

/etc/zabbix/zabbix_agentd.d/repl_pg_mon.sh

3. Настройка UserParameter агента Zabbix

На мастере открываем настройки zabbix агента:

vi /etc/zabbix/zabbix_agentd.conf

Добавляем строку:

UserParameter=pg_repl_mon[*],/etc/zabbix/zabbix_agentd.d/repl_pg_mon.sh

* в данном случае, мы создаем в zabbix агенте пользовательский параметр с именем pg_repl_mon — при его вызове будет запускаться скрипт /etc/zabbix/zabbix_agentd.d/repl_pg_mon.sh, который мы ранее создали.

Перезапускаем агента:

systemctl restart zabbix-agent

Проверяем работу параметра. Для этого с сервера zabbix выполняем команду:

zabbix_get -s 192.168.1.10 -k pg_repl_mon

* данной командой мы обращаемся к серверу 192.168.1.10 (это должен быть адрес сервера, на котором мы настроили агента и скрипт); pg_repl_mon — параметр, который мы вызывает.

... команда должна вернуть либо 0 (если есть проблемы с репликацией), либо 1.

4. Настройка сервера Zabbix

На сервере Zabbix создаем новый шаблон для выполнения запроса к агенту и привязываем его ко всем мастер-хостам СУБД PostgreSQL.

Создание шаблона

Для удобства скачиваем уже готовый шаблон pg_repl_template.xml. Заходим на страницу управления сервером Zabbix и переходим в раздел Настройка - Шаблоны:

Переходим в раздел Настройка - Шаблоны