Zabbix Мониторинг динамических бэкапов

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

Встает вопрос как мониторить актуальное состояние?

Предлагаю свое решение по реализации данной задачи с использованием Zabbix и небольшого скрипта на Python.

Опишу полный цикл своих бэкапов.

1. MSSQL ежедневно делает бэкап базы с перезаписью в одно и тоже место с одним и тем же именем:

Данный файл мониторится просто.

в Zabbix создаем Элемент данных

И на основе него создается тригер который проверяет не прошли ли сутки(86400сек.) с момента последнего бэкапа.

2. Далее Cobian сжимает и переносит данный бэкап в несколько мест. В хранилище на том же сервере, плюс кладет в сетевое хранилище, где циклично обновляет 14 копий.

В которых лежат файлы:

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

Казалось бы можно мониторить дату изменения директории с помощью того же элемента данных что и выше. Но не все так просто. У меня это не заработало. точнее заработало, но не правильно и плохо, дата изменения папки не обновлялась пока в нее не войдешь в ручную, хотя файл бэкапа был с правильной датой. Возможно были где то глюки винды. К тому же это совсем не захотело работать с сетевым путем (\\NAS\backup\ )

По этому собственно и родился данный скрипт:

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

В данной примере бэкап должен быть больше 2MB и он не должен быть старше суток.
Если все ок скрипт передаст в заббикс 0 если что то не так то вернется 1.

В качестве аргумента скрипту передать можно как локальный путь так и сетевой. все прекрасно работает. Главное что бы был доступ.

Как это выглядит в заббиксе.

В первую очередь создаем юзер параметр.

Идем в zabbix_agent.conf и добавляем строку:

Собственно здесь указывается путь к компилятору Python, далее путь до скрипта и параметр который будет взят из ключа check_backup[*]

В заббиксе Создаем элемент данных

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

UPD: Добавил в качестве параметров уникальный размер для каждого бэкапа

В конфиге заббикса соответственно вызывается вот так

в элементах данных соответственно через запятую указывается размер в байтах.

Вот собственно и все. Спасибо за внимание.

Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит приглашение от кого-либо из участников сообщества. До этого момента его username будет скрыт псевдонимом.

Мониторинг размера бэкапа в Zabbix

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

Введение

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

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

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

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

Скрипты по сбору информации о размере бэкапов

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

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

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

1с	имя бэкапа
размер бэкапа в байтах

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

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

Дальше рисуем скрипт, который будет передавать данные в заббикс:

Проверяем его работу следующим образом:

На выходе просто цифра с размером, которая уходит на сервер заббикса. То, что нужно. Важно не забыть один момент, иначе ничего не зааработает. Скрипту нужно назначить владельца zabbix, чтобы агент мог его запускать:

Если этого не сделать, получите ошибку в логе агента:

Настраиваем zabbix агент

Делаем все как обычно. Идем в папку /etc/zabbix/zabbix_agentd.conf.d и создаем файл с пользовательскими параметрами:

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

Все в порядке, агент настроили. Осталось добавить новый итем на сервер.

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

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

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

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

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

Заключение

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

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

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

Мониторинг бэкапов с помощью 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 и ждите поступления данных. Обновляются они раз в час. Получите примерно такую картинку.

Заключение

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