С появлением стандартных готовых шаблонов для различных приложений жизнь с заббиксом стала значительно проще. Сегодня я покажу это на примере мониторинга Mysql сервера в Zabbix 5 с использованием стандартного шаблона. Все стало не просто, а очень просто. Практически ничего делать не надо, разработчики все сделали за нас.
Введение
Напоминаю одну важную деталь. Если вы ставите Zabbix Server не с нуля, а обновляете старую версию, у вас не обновляются стандартные шаблоны. А они последнее время сильно изменились, плюс появились новые. Посмотреть их можно на github — https://github.com/zabbix/zabbix/tree/master/templates.
В данном случае я буду использовать шаблон из директории /db/mysql_agent/. Он написан для старого агента. Напомню, что начиная с версии 4.4 доступна новая версия агента, написанная на Go — zabbix_agent2. Для него появился новый функционал и новые шаблоны. Я пока буду использовать старого агента, так как с новым еще не разбирался.
Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:
То же самое на Debian 10, если предпочитаете его:
Ставьте себе сервер и погнали настраивать.
Подготовка mysql к мониторингу
Для примера настроим мониторинг Mysql на самом сервере мониторинга Zabbix. Так как это часто узкое место производительности системы, мониторинг базы zabbix лишним не будет. Первым делом добавим новые параметры в агенте. Для этого создаем конфигурационный файл /etc/zabbix/zabbix_agentd.d/template_db_mysql.conf следующего содержания.
UserParameter=mysql.ping[*], mysqladmin -h"$1" -P"$2" ping
UserParameter=mysql.get_status_variables[*], mysql -h"$1" -P"$2" -sNX -e "show global status"
UserParameter=mysql.version[*], mysqladmin -s -h"$1" -P"$2" version
UserParameter=mysql.db.discovery[*], mysql -h"$1" -P"$2" -sN -e "show databases"
UserParameter=mysql.dbsize[*], mysql -h"$1" -P"$2" -sN -e "SELECT COALESCE(SUM(DATA_LENGTH + INDEX_LENGTH),0) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='$3'"
UserParameter=mysql.replication.discovery[*], mysql -h"$1" -P"$2" -sNX -e "show slave status"
UserParameter=mysql.slave_status[*], mysql -h"$1" -P"$2" -sNX -e "show slave status"
После этого сразу перезапустим zabbix-agent.
systemctl restart zabbix-agent
Дальше идем в консоль mysql и создаем пользователя, от которого будет работать мониторинг. Ему достаточно ограниченных прав на чтение.
mysql -uroot -p
> CREATE USER 'zbx_monitor'@'%' IDENTIFIED BY 'TTRy1bRRgLIB';
> GRANT USAGE,REPLICATION CLIENT,PROCESS,SHOW DATABASES,SHOW VIEW ON *.* TO 'zbx_monitor'@'%';
> quit
Теперь смотрим, где у нас домашняя директория пользователя zabbix.
cat /etc/passwd | grep zabbix
zabbix:x:990:986:Zabbix Monitoring System:/var/lib/zabbix:/sbin/nologin
У меня ее не было, так что создаем.
mkdir /var/lib/zabbix
Кладем в эту директорию конфиг .my.cnf с реквизитами доступа к серверу mysql.
[client]
user='zbx_monitor'
password='TTRy1bRRgLIB'
Назначаем пользователя zabbix владельцем своей домашней директории и файла в ней. Файлу ограничиваем доступ.
chown -R zabbix. /var/lib/zabbix
chmod 400 /var/lib/zabbix/.my.cnf
Подготовка к мониторингу mysql сервера завершена. Идем теперь в web интерфейс системы мониторинга Zabbix.
Настройка мониторинга Mysql сервера
В веб интерфейсе идем в раздел Настройка -> Шаблоны и импортируем шаблон template_db_mysql_agent.xml.
После этого прикрепляем добавленный шаблон к хосту, где мы только что настроили zabbix-agent и добавили пользователя mysql. Для того, чтобы сразу увидеть все метрики, принудительно выполним сбор данных. Для начала вручную запустим правила автообнаружения, так как у них интервал проверок 1 час. Не хочется столько времени ждать данных. Идем в хост, далее во вкладку Правила обнаружения. Выбираем 2 правила от шаблона mysql и запускаем их.
Ждем несколько секунд и переходим на вкладку Элементы данных. Фильтруем элементы по названию группы MySQL и Zabbix raw items.
Теперь переходим к списку элементов данных. Выделяем все элементы, которые относятся к Mysql и имеют тип Zabbix Agent и запускаем их принудительную проверку. Основной элемент тут — MySQL: Get status variables. Почти все итемы получаются в результате предобработки данных с него.
После этого идем в раздел Мониторинг -> Последние данные и наблюдаем собираемые метрики.
На этом по базовой настройке мониторинга сервера mysql все. Дальше раскрою некоторые нюансы.
Мониторинг репликации MySQL
Вообще, шаблон достаточно навороченный. Там и автообнаружение, и зависимые элементы с предобработкой xml, и предобработка с помощью JavaScript. Рассмотрю отдельно некоторые моменты представленного шаблона zabbix по мониторингу mysql. Во-первых, некоторые параметры задаются с помощью макросов. Вот их список.
Из настраиваемых параметров ясно, что мониторить можно не только локальный mysql сервер, но и удаленный, задав параметры подключения к нему.
Так же в шаблоне реализован мониторинг репликации базы данных. Для этого есть отдельное правила автообнаружения с триггерами. Теперь моя старая статья по мониторингу репликации mysql стала не актуальна. Этот же функционал реализован в базовом шаблоне. Если у вас не настроена репликация, то автообнаружение просто не найдет ничего. Можно это правило выключить.
Для мониторинга репликации автоматически создаются 4 триггера.
- Replication lag is too high (over {$MYSQL.REPL_LAG.MAX.WARN} for 5m) — отставание реплики больше заданного в макросе времени. По умолчанию 30 минут.
- The slave I/O thread is not connected to a replication master — Демон по сбору бинарного лога запущен, но не подключен к мастеру. Его параметр slave_io_running имеет значение не Yes.
- The slave I/O thread is not running — демон по сбору бинарного лога не запущен. Его параметр slave_io_running равен No.
- The SQL thread is not running — демон выполнения команд локального relay лога не запущен. Его парметр slave_sql_running равен No.
В целом, этих четырех метрик достаточно для мониторинга репликации. Я так же настраивал мониторинг именно их.
Триггеры шаблона
Для полноты картины, поясню остальные триггеры шаблона, чтобы у вас было понимание, за чем они следят и как правильно реагировать на них. Ниже список триггеров шаблона для мониторинга mysql сервера.
- Buffer pool utilization is too low (less {$MYSQL.BUFF_UTIL.MIN.WARN}% for 5m) — под innodb пул выделено слишком много памяти и она не используется вся. Триггер чисто информационный, делать ничего не надо, если у вас нет дефицита памяти на сервере. Если нехватка оперативной памяти есть, то имеет смысл забрать немного памяти у mysql и передать другому приложению. Настраивается потребление памяти пулом параметром innodb_buffer_pool_size.
- Failed to get items (no data for 30m) — от mysql сервера не поступают новые данные мониторинга в течении 30 минут. Имеет смысл уменьшить этот интервал до 5-10 минут.
- Refused connections (max_connections limit reached) — срабатывает ограничение на максимальное количество подключений к mysql. Увеличить его можно параметром mysql сервера — max_connections. Его необходимо увеличить, если позволяют возможности сервера. Напомню, что увеличенное количество подключений требует увеличения потребления оперативной памяти. Если у вас ее уже не хватает, нет смысла увеличивать число подключений. Нужно решать вопрос с потреблением памяти.
- Server has aborted connections (over {$MYSQL.ABORTED_CONN.MAX.WARN} for 5m) — сервер отклонил подключений выше заданного порога в макросе. Надо идти в лог mysql сервера и разбираться в причинах этого события. Скорее всего там будут подсказки.
- Server has slow queries (over {$MYSQL.SLOW_QUERIES.MAX.WARN} for 5m) — количество медленных запросов выше установленного макросом предела. Надо идти и разбираться с медленными запросами. Тема не самая простая. Надо заниматься профилированием запросов и решать проблемы по факту — добавлением индексов, редактированием запросов, увеличения ресурсов mysql сервера и т.д.
- Service has been restarted (uptime < 10m) — информационный триггер, срабатывающий на перезапуск mysql сервера (не ребут самого сервера).
- Service is down — служба mysql не запущена.
- Version has changed (new version value received: {ITEM.VALUE}) — версия mysql сервера изменилась. Тоже информационный триггер, сработает, к примеру, после обновления mysql сервера.
На этом по мониторингу MySQL сервера с помощью стандартного шаблона Zabbix все. Надеюсь, я доступно и понятно раскрыл данную тему. Если у вас есть замечания, жду вас в комментариях.
Заключение
Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!
Здорово, что разработчики сами занялись написанием готовых шаблонов для мониторинга сетевых устройств, операционных систем и приложений. Поняли, что это будет способствовать развитию продукта. Многие шаблоны, которые разрабатывали сами пользователи, становятся неактуальными, так как разработчики их делают лучше. Собственно, это и логично. Кто лучше всех знает продукт, как не они. За последнее время появилось много обновления по этой теме. Надеюсь, будет еще больше.
Источник: https://serveradmin.ru/monitoring-mysql-v-zabbix/
Was this helpful?
0 / 0