Мониторинг mysql репликации в zabbix

Введение

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

Установка CentOS.
Настройка CentOS.
Установка и настройка zabbix сервера.

Бэкапы в виде сырых данных в директории (1-й способ)

У меня много где настроена самодельная система бэкапа, похожая на то, что описано в статье по настройке бэкапа с помощью rsync. Не буду подробно останавливаться на том, почему бэкаплю именно так. Во многих случаях это удобно, так как всегда имеешь под рукой свежую версию данных в исходном виде. В случае повреждения источника, просто меняешь точку монтирования и получаешь практически сразу все данные, без простоя рабочего процесса.

На всякий случай хочется следить за тем, что бэкапы у тебя актуальны и в случае чего ты можешь на них рассчитывать. Делать мы это будет по очень простой схеме. На сервере источнике будет раз в сутки создаваться файл. Во время бэкапа этот файл будет улетать на сервер с резервными данными. Этот сервер подключен к системе мониторинга zabbix с помощью агента. Этот агент будет периодически проверять дату последнего изменения файла. Если эта дата больше заданного интервала, то мы будем получать оповещение о том, что бэкапы не выполняются.

Для настройки описанной схемы нам понадобится выполнить несколько шагов:

На серверах источниках настроить скрипт, который будет создавать файл и поместить его в планировщик.
На сервере заббикс настроить на хосте с бэкапами item и trigger для слежения и оповещения о дате файла.

Бэкапы в виде запакованных архивов (2-й способ)

Если у вас бэкапится, к примеру, какая-то база в дамп или есть просто отдельный файл, то имеет смысл его архивировать и хранить в виде одиночного архива. Для таких бэкапов тоже нужен мониторинг. Чтобы следить за актуальностью бэкапа, я предлагаю мониторить 2 параметра:

Размер файла. Если он равен нулю, то срабатывает триггер.
Дата создания бэкапа. Если он старше какого-то срока, в моем примере будут 24 часа, то шлем оповещение.

Мониторинг бэкапов будет настроен из расчета, что у вас все бэкапы лежат в одной директории на сервере. В этой директории резервные копии хранятся для каждого объекта в отдельной папке. Будет настроено автообнаружение папок в директории с бэкапами.

Введение

Установка CentOS 8.
Настройка CentOS 8.
Установка и настройка zabbix сервера.

То же самое на Debian 10, если предпочитаете его:

Установка Debian 10.
Базовая настройка Debian.
Установка и настройка zabbix на debian.

Несколько слов о том, что именно мы будем мониторить. Посмотреть статус репликации можно с помощью простой команды в консоли mysql:

MariaDB > 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 дистрибутиве.

Введение

Я уже много раз использовал внешние скрипты и UserParameter для мониторинга в zabbix. Не буду подробно на этом останавливаться. Приведу список своих материалов по этой теме:

Мониторинг информации из текстовых файлов
Следим за временем делегирования домена в zabbix
Мониторинг бэкапов
Статус транков в астериск
Мониторинг рейда mdadm
Наблюдение за mysql репликацией с помощью заббикс
Состояние веб сервера nginx и php-fpm
Мониторинг температуры windows сервера

Использовать будем такой же подход. У нас будет 2 скрипта. Первый будет собирать информацию о размерах папок с файлами, второй будет передавать сформированные данные в заббикс. Делать все будем раз в сутки, чаще нет смысла, так как у меня бэкапы выполняются с суточным интервалом. Сами бэкапы представляют из себя не отдельные файлы-архивы, а папки. Настроено все примерно так же, как в статье про настройку backup с помощью rsync.

Установка CentOS 7.

Настройка CentOS 7.

Установка и настройка zabbix сервера.

То же самое на Debian 9, если предпочитаете его:

Установка Debian 9.

Базовая настройка Debian 9.

Установка и настройка zabbix на debian.

Введение

То же самое на Debian 10, если предпочитаете его:

Бэкапы в виде сырых данных в директории (1-й способ)

Для настройки описанной схемы нам понадобится выполнить несколько шагов:

Бэкапы в виде запакованных архивов (2-й способ)

Добавляем новый итем на сервер мониторинга zabbix

Кратко расскажу, что делать на сервере. Раньше я уже неоднократно рассматривал этот момент, поэтому не буду на нем подробно останавливаться. Больше информации можете получить в предыдущих статьях, которые я привел в самом начале. Идем в веб интерфейс. Выбираем хост, на котором мы только что настраивали агент, заходим в список итемов и добавляем новый:

Name	Произвольное имя итема.
Key	Название ключа, должно быть точно таким же, как в UserParameter в агенте.
Update interval	Время обновления, в данном случае раз в минуту для отладки, потом рекомендую ставить раз в сутки.
Units	Единица измерения, в данном случае байты.
Use custom multiplier	Пользовательский множитель для корректного перевода в гигабайты

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

Смотреть результат следует, как обычно, в Latest data. Там же можно и график посмотреть, когда накопятся данные для него. Для более наглядных и красивых графиков, необходимо будет их вручную создать в конструкторе графиков конкретного хоста. Лично мне достатчно информации из последних данных.

Подготовка сервера к мониторингу процессов

Первым делом идем на целевой сервер и изменяем конфигурацию zabbix-agent. Нам надо активировать следующую опцию:

EnableRemoteCommands=1

Не забудьте после этого перезапустить агента.

# systemctl restart zabbix-agent

Предупреждаю, что подобная настройка — огромная дыра в безопасности сервера. Используйте на свой страх и риск. Чтобы у вас не было проблем с этим, настоятельно рекомендую ограничивать доступ к порту агента на сервере на уровне firewall только с сервера мониторинга. Так же в обязательном порядке использовать шифрованное соединение между сервером и агентом. Вообще, это универсальное правило при настройке мониторинга. В идеале, так надо делать всегда. Я стараюсь все это настраивать при работе мониторинга через интернет. Если проигнорировать данное предупреждение и оставить все в открытом доступе, то через разрешенные удаленные команды вам могут залить на сервер зловред.

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

# ps aux --sort=-pcpu,+pmem | awk 'NR<=10'

Получаем список запущенных процессов, отсортированный по потреблению cpu и ограниченный первыми десятью строками. В данный момент на сервере с агентом нам делать нечего. Перемещаемся в web интерфейс Zabbix Server.

Настройка мониторинга на Zabbix сервере

Теперь идем на сервер. У меня Zabbix установлен на сервере CentOS, хотя это не принципиально. Добавляем новый Item. Пойти можно двумя путями:

Создать template, в него добавить все items, создать триггеры, графики и назначить этот шаблон нужным серверам.
К каждому серверу отдельно добавлять только необходимые итемы и вручную добавлять триггеры и графики.

Очевидно, что первым путем идти удобнее и разумнее. Я так и поступил, но в процессе реализации столкнулся с проблемой. Не все сервера имеют одинаковый набор датчиков. Где-то я не смог снять температуру с материнской платы, где-то вместо одного процессора, стояло два и хотелось снимать температуру с обоих камней. Как будет в вашем случае — не знаю. Если все серверы однотипные, то создавайте template, если все разные, то вручную добавляйте каждый итем на сервер. Я в итоге сделал и шаблон для одинотипных серверов, и вручную добавлял итемы туда, где имелись отличия от шаблона.

Итак, сначала создадим шаблон. Идем в Configurations — Templates — Create Template. Шаблон я назвал Temperature Windows. Добавил в него Application — Temperature, затем Item CPU Temperatue. Заполняем поля итема как у меня на картинке:

Параметр Temperature.CPU тот же самый, что и в файле конфигурации агента.

По аналогии создаем итем Mother Temperatue:

Сохраняем шаблон. По желанию создаем для него триггеры и графики. Можно и без них. Добавляем шаблон к серверу, который хотим мониторить. Ждем некоторое время и идем проверять входящие данные. Открываем Monitoring — Latest data:

Нажимаем graph и смотрим график:

Теперь добавим в Zabbix еще один сервер для мониторинга, который будет отличаться по конфигурации от предыдущего. На его примере я покажу, как менять настройки клиента и сервера. С этого сервера я не могу снять данные с датчика температуры материнской платы, по какой причине — не знаю, но не AIDA64 ни OpenHardwareMonitor мне температуру не показывают. Ее можно взять по SNTP с этого сервера, но это отдельная тема. В этом сервере 2 процессора и я хочу мониторить температуру обоих.

Запускаем GUI интерфейс и смотрим, какие датчики мы сможем мониторить:

Нас будет интересовать температура обоих ядер процессора. Теперь запускаем OpenHardwareMonitorReport.exe с выводом информации в текстовый файл. Смотрим, как выглядят строки с интересующей нас информацией:

|  +- CPU Package    :       59       59       59 (/intelcpu/0/temperature/6)

|  +- CPU Package    :       53       53       54 (/intelcpu/1/temperature/6)

Создаем два bat файла следующего содержания:

CPU1Temperature.bat

@echo off
for /F "usebackq tokens=7-10" %%a in (`C:\OpenHardwareMonitor\OpenHardwareMonitorReport.exe`) do echo %%b %%c %%d| find "/intelcpu/0/temperature/6">nul && set temper=%%a
echo %temper%

CPU2Temperature.bat

@echo off
for /F "usebackq tokens=7-10" %%a in (`C:\OpenHardwareMonitor\OpenHardwareMonitorReport.exe`) do echo %%b %%c %%d| find "/intelcpu/1/temperature/6">nul && set temper=%%a
echo %temper%

Редактируем конфигурационный файл zabbix_agentd.win.conf агента Zabbix на клиенте. Добавляем в конец две строки:

UserParameter=Temperature.CPU1, C:\OpenHardwareMonitor\CPU1Temperature.bat
UserParameter=Temperature.CPU2, C:\OpenHardwareMonitor\CPU2Temperature.bat

Перезапускаем службу агента, чтобы изменения вступили в силу.

Дальше идем на сервер Zabbix и по аналогии с предыдущим сервером создаем там Итемы мониторинга. Причем итемы создаем не в шаблоне, а в конкретном сервере, который будем мониторить. Параметр key в этих итемах будет соответственно Temperature.CPU1 и Temperature.CPU2 Ждем некоторое время и проверяем результат.

Добавляем новый итем на сервер мониторинга zabbix

Name	Произвольное имя итема.
Key	Название ключа, должно быть точно таким же, как в UserParameter в агенте.
Update interval	Время обновления, в данном случае раз в минуту для отладки, потом рекомендую ставить раз в сутки.
Units	Единица измерения, в данном случае байты.
Use custom multiplier	Пользовательский множитель для корректного перевода в гигабайты

Добавляем новый итем на сервер мониторинга zabbix

Name	Произвольное имя итема.
Key	Название ключа, должно быть точно таким же, как в UserParameter в агенте.
Update interval	Время обновления, в данном случае раз в минуту для отладки, потом рекомендую ставить раз в сутки.
Units	Единица измерения, в данном случае байты.
Use custom multiplier	Пользовательский множитель для корректного перевода в гигабайты

Установка собственного сервера Veliam Box

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

Veliam Center — ядро всей системы. В случае SaaS версии, оно расположено на серверах разработчиков. В версии BOX у вас есть возможность развернуть его у себя. Ядро взаимодействует с базой данных. Вся основная информация хранится в нем.
Veliam Server — сервер мониторинга. Занимается непосредственно сбором данных с объектов мониторинга. Подобных серверов может быть развернуто несколько в зависимости от схемы наблюдаемой инфраструктуры.
Veliam Client — приложение, которое устанавливается на компьютер администратора системы. С помощью этого приложения происходит управление всей системой. Client подключается напрямую к ядру.

Ечли вы знакомы с архитектурой мониторинга Zabbix, то сопоставить с Veliam их можно следующим образом:

Veliam Center — Zabbix Server
Veliam Server — Zabbix Proxy
Veliam Client — Zabbix web interface

Для того, чтобы развернуть Veliam Center у себя, необходимо его скачать. Это можно сделать в личном кабинете, предварительно зарегистрировавшись в нем.

Дистрибутив весит чуть более 200мб. Установить его можно на любую современную Windows систему. Для экономии можно взять Windows 10, не обязательно серверную версию. Если предполагается мониторинг небольшой инфраструктуры, все 3 компонента системы можно установить на один и тот же компьютер или виртуальную машину. Если же потребуется масштабирование, то каждый компонент может быть установлен отдельно.

Инсталлятор показывает требуемое доступное место с большим запасом. Так как все данные будут храниться локально в базе данных, желательно озаботиться наличием свободного места заранее. Непосредственно для установки достаточно будет примерно 1 Гб свободного места на все.

После установки вам нужно будет подключить Veliam Server к Center. Если все установлено локально на один компьютер, то в качестве адреса укажите 127.0.0.1. Логин и пароль по умолчанию — admin / admin.

Если все прошло успешно, то увидите информационное сообщение об этом.

Теперь можно запустить Veliam Client Box (ярлык должен быть на рабочем столе) и подключиться к системе для дальнейшей настройки. Для этого нужно добавить адрес Center в клиенте. Если подключаетесь локально, указываем 127.0.0.1. Но я бы рекомендовал установить клиент на свое рабочее устройство. Так будет просто удобнее. Если вы будете активно использовать систему, то клиент нужен будет постоянно. При подключении используем ту же самую учетную запись — admin / admin.

После того, как вы первый раз подключитесь к Veliam Center, увидите информацию о том, что он не активирован. Активировать пробную версию на 30 дней можно через личный кабинет. Для этого в клиенте перейдите в раздел Активация и нажмите Активировать офлайн.

Скопируйте строку запроса лицензии и переместитесь в личный кабинет https://lic.veliam.com в раздел Лицензии коробочной версии и сертификаты поддержки. Там выберите строку с неактивированной лицензией и далее в поле с запросом лицензии вставьте запрос, который вы скопировали в клиенте. В ответ получите строку с активацией.

Скопируйте ее и вставьте в клиенте в поле Строка активации. Все, ваш Veliam Box активирован и готов к настройке.

Заключение

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

С помощью мониторинга удалось:

выявить и устранить причины потери ресурсов и сократить расход (за счет устранения утечек и отключения лишних потребителей)
начать считать OEE и оперативно реагировать на снижение производительности отдельных участков
сравнивать производительность дневных и ночных смен в онлайн режиме
оптимизировать логику управления производственной линии и поднять ее производительность (за счет перенастройки таймингов насосов и приводов)
предоставить легкий доступ к актуальной информации во время проведения технических советов и совещаний (вместо бумажных отчетов)

В планах:

Подключить к мониторингу удаленные площадки, куда не протянуть провода. Вероятно это будет через радио по lorawan
Разработать весовой контроль подаваемого сырья при помощи интеграции с весовыми терминалами CAS
Разработать мониторинг состояния двигателей за счет контроля потребления энергии и вибродиагностики
Расширить покрытие мониторинга по всему заводу

P.S.