Мониторинг бэкапов с помощью zabbix

Сегодня хочу рассказать о том, как я мониторю самодельные бэкапы с помощью zabbix. Подход немного костыльный, но на вопрос отвечает, ниже расскажу в чем его смысл. Я рассмотрю 2 способа, когда у вас бэкапы в виде директорий с оригинальными файлами, а второй — в виде запакованных архивов.

Введение

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

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

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

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

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

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

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

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

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

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

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

1-й способ

Скрипт создания проверочного файла

Я использую описанную выше схему для бэкапа как windows так и linux серверов. Поэтому скрипта будет 2, для каждой системы. Вот пример такого скрипта для linux:

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

Добавляем этот скрипт в cron:

Раз в день в 15:01 скрипт будет создавать файл, перезаписывая предыдущий.

Делаем то же самое на windows. Создаем файл create-timestamp.bat следующего содержания:

И добавляем его в планировщик windows. Не забудьте указать, чтобы скрипт запускался вне зависимости от регистрации пользователя, то есть чтобы он работал, даже если в системе никто не залогинен.

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

Запустите стандартные скрипты бэкапа, чтобы созданные файлы переместились на резервные сервера. После этого можно приступать к настройке мониторинга за изменением файлов в zabbix.

Настраиваем мониторинг бэкапов через проверку даты изменения файлов

Дальше привычное дело по созданию итемов и триггеров. Идем в панель управления zabbix, открываем раздел Configuration -> Hosts, выбираем сервер, на котором у нас хранятся бэкапы и создаем там итем со следующими параметрами:

На скриншот не влезла вся строка параметра Key, поэтому привожу ее здесь:

/mnt/data/BackUp/xb-share/documents/timestamp	Путь к проверяемому файлу на сервере бэкапов
modify	Время изменения файла. Параметр может принимать значения: access — время последнего доступа, change — время последнего изменения

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

Из текста не понятно, в чем проблема. Про права я догадался. Обновление итема установил раз в 10 минут (параметр update interval), чаще не вижу смысла, можно вообще поставить пару раз в сутки, в зависимости от вашего плана архивации данных.

Теперь создадим триггер для этого элемента данных:

Разберем, что у нас в выражении написано:

xm-backup — сервер, на котором хранятся бэкапы. Мы берем текущее время, вычитаем из него время последнего изменения файла. Если оно больше 172800 секунд (2 суток), то срабатывает триггер. Вы можете сами выбрать подходящий вам интервал времени сравнения в зависимости от плана бэкапа.

Для тестирования работы оповещений отключите в один из дней скрипты на источниках, создающие проверочный файл. Как только он просрочится, сработает триггер.

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

2-й способ

Скрипты сбора информации о бэкапах

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

Внутри следующее содержимое. Каждый час делает резервная копия базы данных.

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

Нам пригодятся несколько скриптов. Первый из них — backup-info.sh. Он будет формировать текстовый файл backup_info.txt, где будет в одну строку указано имя папки с архивом, размер последнего архива, дата создания архива, время создания архива.

В текстовом файле будет следующее:

Я рекомендую разобрать каждую проверку и вручную ее выполнить в консоли, чтобы убедиться, что она работает как и должна и получает правильное значение. В разных дистрибутивах могут быть разные ключи и выводы команд. Например, команда ls может разделять значения одним пробелом, а может несколькими. Так же вывод и порядок столбцов в разных дистрибутивах может быть разный. Я все проверил только в Ubuntu 16. Данные скрипты писались и отлаживались в ней.

Следующий скрипт — backup-time.sh. Он берет значения из текстового файла, который формирует предыдущий скрипт, вычисляет разницу в часах между текущей датой и временем создания последнего бэкапа. Полученную информацию записывает в файл backup_time.txt.

Тестовый файл будет следующего содержания.

Рисуем скрипт backup-discovery.sh, который будет выполнять автообнаружение папок с архивами и передавать данные в json формате на zabbix сервер.

Запустите файл и проверьте, что он корректно формирует вывод. Должно быть примерно следующее.

И еще 2 скрипта, которые будут непосредственно отдавать информацию заббикс серверу. Первый — analize-size.sh. Он будет передавать серверу информацию о размере архива.

И второй — analize-time.sh. Он передает информацию о времени создания бэкапа относительно текущего.

В завершении делаем пользователя zabbix владельцем всех скриптов и текстовых файлов. Если забыть это сделать, то потом получите ошибку и неактивный итем на сервере.

Добавляем в zabbix-agent информацию о бэкапах

Теперь нам нужно добавить новые итемы в агент заббикса через UserParameter.Создаем файл /etc/zabbix/zabbix_agentd.d/backup_info.conf следующего содержания.

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

Вы должны увидеть список папок в json формате, как при ручном запуске скрипта. Дальше проверим вывод информации о самих бэкапах.

Если получаете актуальную информацию, значит все в порядке. Можно переходить на zabbix-server.

Добавляем шаблон с мониторингом бэкапов на сервер

Здесь вам ничего руками делать не надо будет, так как шаблон я уже сделал и экспортировал в файл — zabbix-backup-info.xml. Экспорт выполнен с версии 3.4. Заработает ли на предыдущих версиях — не знаю, не проверял.

В шаблоне создано одно правило автообнаружения с двумя прототипами итемов и триггеров. Итемы имеют такие настройки:

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

Заключение

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

Мониторинг значений из текстового файла в Zabbix

Недавно мне досталась любопытная задача по мониторингу системы управления насосами и электрооборудованием. Как сами эти системы работают не знаю, для меня значения с контроллеров вывели в текстовые файлы на компьютере под управлением Windows. Моей задачей было передать параметры из текстового файла в систему мониторинга Zabbix.

Введение

Если у вас еще нет готовой системы мониторинга, можете воспользоваться моей статьей по установке и настройке zabbix на centos или freebsd.

Задача по своей сути не сложная. Нечто похожее я уже делал, когда настраивал мониторинг температуры процессора в windows сервере. Мы берем текстовый файл, парсим его с помощью bat файлов и передаем готовые числовые или строковые значения в Zabbix через windows агента и функционал UserParameter.

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

Скрипты для парсинга значений

Первый текстовый файл имел примерно такое содержание:

Описание возможных значений параметров:

• state_pump может принимать значения on или off
• running_time_pump имеет нарастающее числовое значение
• sensor может принимать 3 значения: empty, full, overflow
• general_state либо ОК, либо номер ошибки

Рисуем батник для первого параметра. Если значение on, передаем в заббикс 1, если off — 0.

Обращаю внимание на то, что у меня имя файла было на русском языке. Чтобы его корректно обрабатывало, необходимо сохранить файл в кодировке OEM 866. ПО крайней мере так она называлась в Notepad++, который я использовал для изменения кодировки. Это была самая простая задача, которая решилась прямо в лоб. По аналогии написал скрипт для параметра sensor:

Дальше пришлось соображать, как передать числовое значение, обрезав все, что стоит перед ним. Наверное, для любого программиста это простая задача, для скрипта в linux я тоже не вижу больших проблем придумать что-нибудь с sed, cat, grep или чем-то еще. Но тут у меня в распоряжении bat. Можно было на vbs написать, но для меня это было бы еще сложнее.

Начал читать документацию по for и find, смотреть примеры и пробовать. В итоге все получилось очень просто и коротенько, но повозиться мне пришлось прилично, пока родились эти строки:

Подробно описывать не буду, что тут к чему, при желании сами можете поискать описание параметров. Обращу внимание только на строку set d=%str:

21,25%. Она меня очень выручила. Наткнулся где-то в примере на описание обрезания строк по заданным колонкам. Тут мы выводим значения с 21 по 25 колонки найденной строки. Как раз то, что мне нужно. На выходе просто цифры, которые отлично принимает zabbix.

Обработку параметра general_state делаем аналогичным способом:

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

Второй текстовый файл был примерно такого содержания:

Здесь по аналогии делается все так же, как и в первом примере за одним исключением. Я в какой-то момент поставил в команде find ключ /i, который означает, что значение ищется без учета регистра. В итоге в новом файле я получил проблемы при поиске строк, где есть слово power. Таких строк несколько, причем первая точно повторяет 6-ю, где встречается точно такая же конструкция:

Или еще пример со строками:

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

То есть я нахожу первую и нужную мне строку с active_power, а вторую, где тоже есть эта фраза пропускаю, так как она начинается с символа R. Такой вот костыль придумал, но тем не менее поставленную задачу эта конструкция решает. Рассказываю об этом, чтобы поделиться опытом и самому потом не забыть эти подходы. В итоге я просто убрал ключ /i в команде find и поиск стал работать с учетом регистра без лишних телодвижений.

Распарсил в итоге второй файл. Проверять работу скриптов нужно в командной строке, просто их запуская. На выходе вы должны получать готовые значения, без лишних строк. Теперь двигаемся дальше и настраиваем zabbix agent на сбор данных.

Добавляем UserParameter в zabbix agent

Открываем конфигурационный файл агента и добавляем в самый конец новые параметры, которые будет собирать zabbix:

И так далее. Не стал приводить полный вывод своего файла. По аналогии делаете у себя. Первое значение это название ключа, который будет указан в итеме на сервере, второе это путь к батнику.

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

Если у вас все работает и значения правильные выводятся, идем на сервер, настраивать сбор параметров.

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

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

Создаем новый итем в хосте, либо шаблоне. Указываете следующие обязательные параметры (я рекомендую использовать английский язык везде):

Имя	Произвольное имя итема
Тип	В общем случае используются пассивные проверки (Zabbix agent)
Ключ	Название ключа, который указан в агенте в UserParameter
Тип данных	Выбираете в зависимости от типа поступаемых данных. В моем случае это были цифровые целые или с плавающей точкой, если значения дробные, и текстовые. Здесь важно не перепутать тип. Если перепутаете, получите ошибку итема.
Интервал обновления	Как часто будут поступать новые данные

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

Заключение

Подобным способом можно настроить мониторинг любых значений текстового файла. Достаточно его распарсить нужным образом. Хотя в большинстве случаев это будет костылем. У заббикса очень много способов получения данных. Лучше обходиться без промежуточных звеньев в виде текстового файла и передавать данные напрямую в zabbix. Но конкретно в данной ситуации это было самое простое и быстрое решение.