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

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

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

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

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

На Master

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

sudo -u postgres createuser -P mon_replication

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

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

ps aux | grep postgres | grep — -D

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

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

host template1 mon_replication 127.0.0.1/32 md5

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

systemctl restart postgresql-9.6

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

На Slave

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

sudo -u postgres psql -c «SELECT * FROM pg_user;»

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

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

host template1 mon_replication 192.168.1.10/32 md5

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

systemctl restart postgresql-9.6

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

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

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

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

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

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

* где mon_replication — созданный нами пользователь; 127.0.0.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 — их разница показывает отставание реплики и должна либо равняться нулю, либо отличаться на небольшое число.

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

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

apt-get install bc

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

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

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

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`

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

* в данном скрипте мы подключаемся к базе мастер и получаем позицию репликации последней отправки данных на слейв, затем к базе вторичного сервера и получаем позицию репликации последнего получения данных; после — мы парсим значения двух параметров и преобразовываем шестнадцатеричное их значение в десятичное. Если разница этих значений больше 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

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

Блог ID

Умный дом и самодельные устройства

Мониторинг PostgreSQL в Zabbix

Введение:

Disclaimer: Любые необдуманные действия в вашей производственной среде могут закончиться крахом сервисов. Тестируйте!

Страница проекта: https://github.com/lesovsky/zabbix-extensions/tree/master/files/postgresql

В примере использованы: Zabbix сервер на базе CentOs 7.0 и PostgreSQL 9,6 сервер на базе Ubuntu server 16,04.

На сервере PostgeSQL необходимо установить zabbix-agent, загрузить с GitHub соответствующее расширение, а также активировать расширения pg_buffercache и pg_stat_statements через консоль PostgeSQL, разрешить локальный доступ к базе в файле pg_hba.conf, после чего перечитать конфиг PostgreSQL.

На Zabbix сервер необходимо загрузить соответствующий шаблон и задать макрос. Т.к. шаблон сделан для версии Zabbix не ниже 3.4, то для примера привожу процесс обновления сервера Zabbix.

Обновление Zabbix 3,0 до версии 3,2:

systemctl stop zabbix-server

yum install http://repo.zabbix.com/zabbix/3.2/rhel/7/x86_64/zabbix-release-3.2-1.el7.noarch.rpm

yum install zabbix-server-mysql zabbix-web-mysql zabbix-agent

systemctl start zabbix-server

systemctl start zabbix-agent

Обновление Zabbix 3,2 до версии 3,4:

systemctl stop zabbix-server

rpm -Uvh http://repo.zabbix.com/zabbix/3.4/rhel/7/x86_64/zabbix-release-3.4-1.el7.centos.noarch.rpm

yum install zabbix-server-mysql zabbix-web-mysql zabbix-agent

systemctl start zabbix-server

systemctl start zabbix-agent

Установка агента Zabbix на сервер PGSQL:

sudo wget https://repo.zabbix.com/zabbix/3.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_3.4-1+xenial_all.deb
sudo dpkg -i zabbix-release_3.4-1+xenial_all.deb
sudo apt update

Для других версий ОС Ubuntu, слово «xenial» заменить названием соответствующего дистрибутива, например, для 14.04 «trusty»:

sudo wget https://repo.zabbix.com/zabbix/3.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_3.4-1+trusty_all.deb

sudo apt-get install zabbix-agent

редактируем конфиг файл:

sudo nano /etc/zabbix/zabbix-adgentd.conf

находим секцию Option: Server и после Server=127.0.0.1, через запятую прописываем ip адрес сервера Zabbix:

тоже самое делаем в секции Option: ServerActive. для примера:

Сохраняем файл и перезапускаем агента:

sudo service zabbix-agent restart

Установка расширения на сервере PGSQL:

sudo git clone https://github.com/lesovsky/zabbix-extensions

sudo mkdir /etc/zabbix/zabbix_agentd.d/

sudo cp files/postgresql/postgresql.conf /etc/zabbix/zabbix_agentd.d/

Активируем расширения postgresql:

sudo su postgres

где, dbname имя базы данных.

\dx — просмотр установленных расширений.

CREATE EXTENSION pg_stat_statements;

CREATE EXTENSION pg_buffercache;

Разрешаем локальный доступ к базе, для чего редактируем:

sudo nano /etc/postgresql/9.6/main/pg_hba.conf

host all all 127.0.0.1/32 trust (ну, или для конкретной базы)…

перечитываем конфиг-файлы postgres:

service postgresql reload

Загрузка шаблона мониторинга PGSQL на Zabbix сервер:

Скачиваем файл шаблона postgresql-extended-template.xml со страницы проекта на гитхабе:

Открываем веб-интерфейс zabbix, идем в Настройка => Шаблоны и жмём кнопку «Импорт»

Выбираем загруженный ранее шаблон в формате xml.

После успешной загрузки идем в Настройка => Узлы сети и, если не создан таковой ранее, создаем новый узел сети для нашего сервера postgres, затем добавляем стандартный шаблон «OS Linux» и шаблон «DB PostgreSQL».

И остается только заполнить данные макроса, для опроса базы данных:

<$PG_CONNINFO>-h 127.0.0.1 -p 5432 -U postgres -d DBName
<$PG_CONNINFO_STANDBY>-p 5432 -U postgres -d DBName

где, dbname — имя вашей базы.

Всё. Теперь можно просматривать графики:

Мониторинг PostgreSQL в Zabbix : 1 комментарий

А как мониторить несколько баз на одном сервере?
А то получается, что на один хост можно привязать только одну базу?

Мониторинг PostgreSQL с использованием Zabbix

Доклад Дарьи Вилковой для Zabbix Meetup Online

Я хочу познакомить вас со средством мониторинга PostgreSQL и операционной системы, которое разрабатывается нашей компанией с использованием Zabbix.

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

Мы создали активный агент — Mamonsu, который обеспечивал более гибкий мониторинг, чем на тот момент позволяли стандартные средства, и обеспечивал сбор метрик и их отправку на Zabbix Server. В нашей компании Mamonsu используется при проведении аудита.

Mamonsu

Mamonsu — активный агент (Zabbix Trapper) для мониторинга PostgreSQL и операционной системы. Mamonsu (написанный на Python) позволяет настроить параметры мониторинга PostgreSQL и операционной системы за пять минут.

Mamonsu обладает дополнительными инструментами:

• mamonsu tune — команда, редактирующая параметры настройки в конфигурационном файле PostgreSQL под машину на который установлен агент Mamonsu.
• mamonsu report — команда, создающая ответы об операционной системе и PostgreSQL.

Mamonsu устанавливается на сервер СУБД, собирает информацию, компонует ее в JSON, который отправляет для визуализации на Zabbix Server, где должен быть шаблон для его метрик.

Схема работы Mamonsu

Возможности Mamonsu

На данный момент мы предлагаем множество плагинов и в каждой следующей версии стараемся добавить что-то новое.

• 14 плагинов для PostgreSQL,
• 8 плагинов для OS Linux,
• 4 плагина для OS Windows.

Mamonsu собирает более 110 метрик PostgreSQL и операционных систем:

• 70 метрик PostgreSQL,
• 40 метрик OS Linux,
• 8 метрик OS Windows.

Основные метрики включают доступность СУБД, количество соединений, размер базы данных, чекпойнты, скорость чтения/записи, блокировки, количество процессов автовакуум и скорость генерации WAL. Полный список доступных метрик, а также подробное описание всех инструментов доступны в репозитории на сайте GitHub.

Список доступных метрик на сайте GitHub

Запуск Mamonsu за 5 минут

Для настройки мониторинг PostgreSQL и операционной системы с помощью Mamonsu можно за 5 минут, выполнив 5 простых действий.

1. Установка Mamonsu. Mamonsu можно собрать из исходников или воспользоваться доступными пакетами.

$ git clone . && cd mamonsu && python setup.py

build && python setup.py install

1. Настройка соединений. Необходимо прописать параметры соединения c PostgreSQL и Zabbix Server в файле agent.conf.

1. Экспорт шаблона в Zabbix Server.

$ mamonsu zabbix template export

1. Добавление узла сети в Zabbix Server. Экспортированный шаблон будет автоматически подключен к новому узлу сети на Zabbix Server.

$ mamonsu zabbix host create mamonsu-demo

$ service mamonsu start

Направления развития Mamonsu

В рамках развития Mamonsu мы планируем дорабатывать метрики и создавать новые плагины, например плагин мониторинга размера отдельных таблиц. Мы также планируем улучшать и создавать дополнительные инструменты, а также расширять возможности автонастройки через команду mamonsu tune.

Модуль мониторинга PostgreSQL в составе Zabbix Agent 2

Для соединения с PostgreSQL используется быстрый и популярный драйвер pgx (PG driver and toolkit for Go).

Пока мы используем два интерфейса: Exporter, вызывающий обработчик по ключу, и Configurator Zabbix Agent 2, который считывает и проверяет параметры соединения с сервером, заданные в конфигурационном файле.

Мы постарались оптимизировать работу СУБД, группируя метрики и используя обработчик (handler) для метрик и групп метрик, а также используя группы метрик в JSON как зависимые переменные (dependency items), и низкоуровневое обнаружение (discovery rules).

Основные возможности

Уровни параметров подключения к PostgreSQL

Всего доступны три уровня параметров подключения к PostgreSQL, т. е. задач и настроек:

Параметры Global задаются на уровне агента, параметры Session и Macros определяют параметры подключения базе.

Параметры подключения к PostgreSQL — Sessions задаются в файле zabbix_agent2.conf.

Параметры подключения к PostgreSQL — Sessions

• После ключевого слова Sessions указывается уникальное имя сессии, которое должно быть указано в ключе (шаблоне).
• Параметры URI и UserName обязательны для каждой сессии.
• Если имя базы не задано, используется общее по умолчанию имя базы для всех сессий для PostgreSQL, которое также задается в конфигурационном файле.

1. Параметры подключения к PostgreSQL — Macros задаются в ключе метрики в шаблоне (аналогично способу, использованному в Zabbix Agent 1), т. е. создаются в шаблоне и далее указываются как параметры в ключе. При этом последовательность макросов фиксирована, т. е., например, URI всегда указывается на первом месте.

Параметры подключения к PostgreSQL — Macros

Модуль мониторинга PostgreSQL включает уже более 95 метрик, которые позволяют охватить довольно широкий объем параметров PostgreSQL, включая:

• количество соединений,
• объем баз данных,
• архивация wal-файлов,
• контрольные точки,
• количество «раздувшихся» таблиц,
• статус репликации,
• отставание реплики.

Метрики PostgreSQL не информативны без параметров операционной системы. Но Zabbix Agent 2 уже умеет собирать параметры операционной системы, поэтому для получения полной картины просто подключаем к узлу сети необходимые шаблоны.

Обработчик (handler)

Обработчик (handler) — основная единица модуля, в которой выполняется сам запрос и которая позволяет получать метрики.

Чтобы получить простую метрику:

1. Создаем файл для получения новой метрики:

zabbix/src/go/plugins/postgres/handler_uptime.go

1. Подключаем пакет и указываем уникальный ключ (ключи) метрик:

1. Создаем обработчик (handler) с запросом, т. е. инициируем переменную, в которой будет результат:

Необходимо проверить запрос на предмет ошибок, после чего результат будет подхвачен процессом Zabbix Agent 2.

1. Регистрируем ключ новой метрики:

После регистрации метрики можно пересобирать агент с новой метрикой.