Мониторинг MySQL репликации в Zabbix
Я активно использую репликацию mysql в своей работе, причем как master-slave, так и master-master. Иногда возникают ошибки, и если за ними не следить, то в определенный момент станет очень грустно, когда окажется, что резервный сервер не имеет актуальную версию базы. Чтобы не грустить по этому поводу, мы настроим мониторинг Mysql репликации с помощью Zabbix.
Несколько слов о том, что именно мы будем мониторить. Посмотреть статус репликации можно с помощью простой команды в консоли mysql:
MariaDB [(none)]> show slave status\G;
Нас будут интересовать три параметра:
- Seconds_Behind_Master — то, насколько слейв сервер отстает от мастера в репликации.
- Slave_IO_Running — индикатор работы демона по сбору бинарного лога с мастера и записи его в локальный relay лог.
- Slave_SQL_Running — индикатор выполнения команд из локального relay лога.
Первый параметр в идеале должен равняться нулю, то есть slave сервере следует за мастером непрерывно. Если значение начинает увеличиваться, срабатывает триггер и оповещает о том, что реплика начинает отставать. Два других параметра должны выдавать значение Yes. Если это не так, то тоже срабатывает триггер и шлет оповещение о том, что репликация не работает.
Реализовывать будем так же как и в случае с мониторингом nginx и php-fpm через скрипт и UserParameter. Если у вас репликация master-mastert, то настраиваете мониторинг на обоих серверах.
Я буду настраивать мониторинг на сервере CentOS 7, но в данном случае это не имеет принципиального значения. Настройки будут идентичны практически на любом linux дистрибутиве.
Добавление пользователя mysql
Прежде чем начать настраивать сам мониторинг, выполним необходимые предварительные действия.
Создаем в mysql юзера, у которого будет доступ к информации о репликации:
# mysql -uroot -ppassword
MariaDB [(none)]> CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'parol'; MariaDB [(none)]> GRANT REPLICATION CLIENT ON *.* TO 'zabbix'@'localhost' IDENTIFIED BY 'parol';
Создали учетную запись zabbix с паролем parol и правами replication client. Её мы будем использовать в дальнейшей работе.
Создание скрипта для мониторинга mysql репликации
Теперь создадим скрипт для мониторинга. Скачиваем его отсюда mysql-slave.sh и вставляем содержимое в папку /etc/zabbix/scripts:
# mcedit /etc/zabbix/scripts/mysql-slave.sh # chown zabbix:zabbix /etc/zabbix/scripts/mysql-slave.sh # chmod 550 /etc/zabbix/scripts/mysql-slave.sh
Проверяем его работу:
/etc/zabbix/scripts/mysql-slave.sh Master_Host zabbix parol
Скрипт должен вернуть в консоль имя мастера.Если вы будете проверять работу скрипта от пользователя root, обязательно удалите временный файл из папки /tmp, который создает скрипт. Если этого не сделать, то потом заббикс не сможет его прочитать, так как ему не хватит для этого прав.
Данный скрипт анализирует вывод show slave status\G и парсит 3 необходимых нам значения. Он передает агенту информацию о задержке репликации через параметр Seconds_Behind_Master и анализирует значения Slave_IO_Running и Slave_SQL_Running. Если их значения равны Yes, он передает агенту 1, если там что-то другое то 0.
Настройка zabbix agent
Добавляем новый параметр в zabbix_agentd.conf
# mcedit /etc/zabbix/zabbix_agentd.conf UserParameter=mysql-slave[*],/etc/zabbix/scripts/mysql-slave.sh "$1" zabbix parol
Сохраняем конфиг и перезапускаем агента:
# systemctl restart zabbix-agent
Настройка мониторинга репликации mysql на zabbix server
Здесь все как обычно. Скачиваем шаблон mysql-slave.xml импортируем его на сервер. Для этого идем в Configuration -> Templates и нажимаем Import:
Выбираем скачанный шаблон и жмем Import:
Дальше отправляемся к списку хостов в Configuration -> Hosts, выбираем нужный хост и назначаем ему новый шаблон:
Жмем Update для применения настроек. Ждем несколько минут и идем проверять поступление новых данных репликации mysql. Открываем Monitoring -> Latest Data, настраиваем фильтр и проверяем значения:
В данном случае мы видим, что значение Seconds Behind Master = 0, отставания от мастера нет. Два других значения равны единице, это значит, что наш скрипт проверки состояния репликации получает статусы Slave_IO_Running и Slave_SQL_Running равные Yes и поэтому возвращает значения 1. То есть наша репликация работает в штатном режиме, все в порядке.
Проверка работы триггеров
Попробуем нарушить работу репликации mysql и проверим работу триггеров. Для этого я просто отключу vpn соединение, по которому доступны сервера. После разрыва связи на slave сервере следующая картинка статуса репликации:
Проверяем данные мониторинга репликации:
Значение Slave_IO_Running сменилось с Yes на Connecting и скрипт проверки вернул значение 0 вместо 1. Этого достаточно, чтобы сработал триггер и пришло оповещение о том, что репликация mysql сервера нарушена:
На почту пришло оповещение:
По-умолчанию мониторинг не умеет отправлять оповещения на сторонние серверы с авторизацией по smtp.
Восстанавливаем связь между серверами и ждем новой работы триггера и уведомления:
Проверяем Latest Data:
Все в порядке, мониторинг нормально отработал нарушение mysql репликации. Больше тут настраивать нечего, графики и экраны не нужны, в них нет необходимости. На этом работа по настройке мониторинга окончена.
Заключение
Для мониторинга состояния репликации mysql мы воспользовались самописным скриптом, который парсит вывод значения show slave status\G и анализирует необходимые нам параметры реплики. На основе этих параметров он передает zabbix агенту необходимые значения для отправки на сервер.
На сервер мониторинга мы импортировали готовый шаблон для сбора данных и работы триггеров. Подключили этот шаблон к хосту и посмотрели значения, которые он получает. Так же проверили срабатывание триггеров, принудительно нарушив работу репликации. Таким образом убедились, что мониторинг корректно отрабатывает нештатные ситуации.
