Мониторинг размера бэкапа в Zabbix
Ранее я уже рассказывал, как мониторить бэкапы с помощью zabbix. Захотелось собирать информацию о размере бэкапа, чтобы смотреть тренды по его увеличению или уменьшению. Немного пораскинул мозгами и придумал решение задачи по мониторингу размера бэкапов с помощью уже привычного инструмента UserParameter.
Содержание:
- 1 Введение
- 2 Скрипты по сбору информации о размере бэкапов
- 3 Настраиваем zabbix агент
- 4 Добавляем новый итем на сервер мониторинга zabbix
- 5 Заключение
- 6 Дополнительные материалы по Zabbix
Введение
Я уже много раз использовал внешние скрипты и UserParameter для мониторинга в zabbix. Не буду подробно на этом останавливаться. Приведу список своих материалов по этой теме:
- Мониторинг информации из текстовых файлов
- Следим за временем делегирования домена в zabbix
- Мониторинг бэкапов
- Статус транков в астериск
- Мониторинг рейда mdadm
- Наблюдение за mysql репликацией с помощью заббикс
- Состояние веб сервера nginx и php-fpm
- Мониторинг температуры windows сервера
Использовать будем такой же подход. У нас будет 2 скрипта. Первый будет собирать информацию о размерах папок с файлами, второй будет передавать сформированные данные в заббикс.
Делать все будем раз в сутки, чаще нет смысла, так как у меня бэкапы выполняются с суточным интервалом. Сами бэкапы представляют из себя не отдельные файлы-архивы, а папки.
Настроено все примерно так же, как в статье про настройку backup с помощью rsync.
Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:
- Установка CentOS 7.
- Настройка CentOS 7.
- Установка и настройка zabbix сервера.
То же самое на Debian 9, если предпочитаете его:
- Установка Debian 9.
- Базовая настройка Debian 9.
- Установка и настройка zabbix на debian.
Скрипты по сбору информации о размере бэкапов
Первый скрипт будет проверять размер каталогов и записывать результат в текстовый файл.
Сначала я собирал размер в байтах, потом решил скриптом преобразовывать в гигабайты, но через некоторое время нашел способ в заббиксе преобразовывать размер из байтов в гигабайты и снова стал в заббикс передавать только байты. Так оказалось удобнее всего. Создаем папку для скриптов и кладем туда сам скрипт:
# mkdir /etc/zabbix/scripts
# mcedit /etc/zabbix/scripts/size-backup-dir.sh#!/bin/bash # Файл с информацией о размере папок logfile=/etc/zabbix/scripts/size-log.txt # Удаляем файл предыдущей работы скрипта rm $logfile # Определяем размер папки size_1c=`du -s /mnt/data/backup/1c | awk '{print $1}'` # Записываем результат в текстовый файл
echo 1c $size_1c >> $logfile
Если у вас несколько папок с бэкапами, добавляете их все в скрипт.
Можно автоматизировать этот процесс, задать переменные с названиями папок с бэкапами и в цикле их перебирать, но у меня это не получилось, так как пути сильно разные. Пришлось все в ручную добавлять.
Я привожу пример с одной папкой. Остальные по аналогии добавляете, не забывая изменять имена переменных, в которые передается размер директории.
Результатом работы скрипта будет файл следующего содержания:
# cat size-log.txt
1c 41374052
| 1с | имя бэкапа |
| 41374052 | размер бэкапа в байтах |
Необходимо добавить этот скрипт в крон и выполнять раз в сутки. Находите конфиг крона в вашей системе и добавляете туда:
30 15 * * * /etc/zabbix/scripts/size-backup-dir.sh
Время выбираете на свое усмотрение. В данном случае у меня отдельный сервер для бэкапов, его можно днем напрячь, когда он простаивает.
Дальше рисуем скрипт, который будет передавать данные в заббикс:
# mcedit /etc/zabbix/scripts/send-zabbix-size.sh#!/bin/bash
cat /etc/zabbix/scripts/size-log.txt | grep $1 | cut -d ” ” -f 2
Проверяем его работу следующим образом:
# ./send-zabbix-size.sh 1c
41374052
На выходе просто цифра с размером, которая уходит на сервер заббикса. То, что нужно. Важно не забыть один момент, иначе ничего не зааработает. Скрипту нужно назначить владельца zabbix, чтобы агент мог его запускать:
# chown zabbix. /etc/zabbix/scripts/send-zabbix-size.sh
Если этого не сделать, получите ошибку в логе агента:
sh: 1: /etc/zabbix/scripts/send-zabbix-size.sh: Permission denied
Настраиваем zabbix агент
Делаем все как обычно. Идем в папку /etc/zabbix/zabbix_agentd.conf.d и создаем файл с пользовательскими параметрами:
# mcedit /etc/zabbix/zabbix_agentd.conf.d/backup-size.confUserParameter=size.1c,/etc/zabbix/scripts/send-zabbix-size.sh 1c
Сохраняем файл. Перезапускаем агента и проверяем в консоли, что улетит на сервер:
# zabbix_agentd -t size.1c
size.1c [t|41374052]
Все в порядке, агент настроили. Осталось добавить новый итем на сервер.
Добавляем новый итем на сервер мониторинга zabbix
Кратко расскажу, что делать на сервере. Раньше я уже неоднократно рассматривал этот момент, поэтому не буду на нем подробно останавливаться. Больше информации можете получить в предыдущих статьях, которые я привел в самом начале. Идем в веб интерфейс. Выбираем хост, на котором мы только что настраивали агент, заходим в список итемов и добавляем новый:
| Name | Произвольное имя итема. |
| Key | Название ключа, должно быть точно таким же, как в UserParameter в агенте. |
| Update interval | Время обновления, в данном случае раз в минуту для отладки, потом рекомендую ставить раз в сутки. |
| Units | Единица измерения, в данном случае байты. |
| Use custom multiplier | Пользовательский множитель для корректного перевода в гигабайты |
Сохраняем новый итем и ждем поступления данных. В случае указания большого интервала обновления, к примеру, раз в сутки, я не знаю, когда заббикс первый раз проведет опрос.
Будет здорово, если кто-нибудь подскажет. Меня всегда интересовал этот момент. Во время отладки я ставлю маленький интервал обновления, например минуту или две.
После того, как убеждаюсь, что все работает корректно, изменяют интервал на необходимый.
Смотреть результат следует, как обычно, в Latest data. Там же можно и график посмотреть, когда накопятся данные для него. Для более наглядных и красивых графиков, необходимо будет их вручную создать в конструкторе графиков конкретного хоста. Лично мне достатчно информации из последних данных.
Заключение
С помощью внешних скриптов настроили еще один тип мониторинга для бэкапов.
Если у кого-то есть мысли на тему того, что нужно мониторить у резервных копий, высказывайте пожелания, попробую реализовать.
Я очень внимательно отношусь к бэкапам и помимо автоматических проверок стараюсь время от времени заходить и глазами проверять все ли в порядке, на месте ли данные и можно ли их восстановить.
На своем опыте убедился в необходимости таких проверок. Приходилось сталкиваться с отказами различных систем, в том числе и коммерческих.
Сервис может тупо зависнуть или выключиться, а ты надеешься на оповещения об ошибках, а раз не получаешь их, думаешь, что все в порядке, а на самом деле у тебя нет резервных копий.
Еще вариант, с которым приходилось сталкиваться, это когда вроде все в порядке, никаких ошибок нет, а во время восстановления получаешь ошибку чтения данных.
Было бы неплохо автоматизировать восстановление данных и сравнение их с оригиналом для стопроцентной уверенности в том, что у тебя живые копии. Но для этого нужны дополнительные ресурсы.
Источник: http://problem-info.ru/monitoring-razmera-bekapa-v-zabbix.html
Как узнать, что бекап прошел успешно
Приветствую! Всем известно, что админы делятся на тех кто еще пока не делает бекапы и на тех, кто уже делает бекапы. Однако, есть мнение, что еще бывают и такие, кто свято убежден, что бекапы делаются, а на деле это не так. В этом посте мне бы хотелось рассказать парочку реальных историй и (если получится) подвести итоги, сделать выводы.
Disclaimer: все истории правдивы, но кое-где обрезал края, образ компании и админа собирательный, все имена изменены, лица искажены до неузнаваемости, мой первый топик, бла-бла-бла, одинодин… Вводная: представим компанию, как классическую компанию разработчиков: активно использует систему контроля версий (subversion — в нашем случае это важно), систему сборки версий, ну, и в нагрузку системы таскооборотов и вики. Объемы большие, потеря данных стоит больших денег, все должно работать «как часы» и «а если вдруг пожар» никого не волнует — данные хранить надо! Будем считать, что бекапы после того, как они сделаны автоматически попадают на магн. ленту/dvd в сейфе ген.директора/ячейку в швейцарском банке, поэтому у нас нет проблемы с доступностью последнего бекапа.
История номер раз
Прелонч
Админ пишет скрипт, который делает бекап баз данных и пишет об этом в лог.
Драма
Админ поднимает из бекапов дампы, аккуратно сложенные в папочки дата_время и видит там, что файлы дампов, начиная с «полгода_тому_назад», имеют нулевой размер.
После грозы
Ошибка была, как минимум, забавной. Вместо
mysqldump db > db.sql &2>> log.txt
было написано
mysqldump db > db.sql &>> log.txt
На самом деле, то что запись в логи добавлялись именно при помощи >> и спасло ситуацию, помогло избежать самого страшного, но это, конечно, очень большая удача. Когда была найдена ошибка и файл log.txt размером в десяток гигабайт было делом техники найти нужные строки ближе к концу файла и развернуть-таки дамп.
История номер два
Прелонч
Админ пишет скрипт который при помощи svnadmin делает дамп всего репозитория и кидает копию на бекап сервер. «А если что-то где пойдет не так?» Сделав правильные выводы из «истории номер раз» Админ добавляет логирование, что в такой-то день была забекаплен репозиторий на столько-то байт.
Драма
На самом деле, драмы удалось избежать, но, опять же, повезло, все могло быть существенно хуже. Хотелось сделать второй svn сервер, некую песочницу, чуть позже захотелось на него раз в день накатывать самый свежий дамп.
При решении этой задачи Админ выяснил, что файл дампа репозитория, начиная с какого-то дня битый. При этом проверка на размер успешно проходила — все ревизии-то до этой критичной бекапились.
После грозы
В этот раз виноват был svnadmin, который делает полный бекап итерационно, начиная с самой первой ревизии. Какая-то ревизия посередине была битой, svnadmin доходил до нее, ломался, честно об этом сообщал и уходил в себя.
Начиная отсюда всех подробностей, к сожалению, не знаю, но они нам не очень-то и важны. Починить ревизию не было возможности, удалить ее тоже не было возможности (не знаю, кстати, опять же, как обстоят дела с этим в свежих версиях subversion'а).
Поэтому было принято командирское решение переносить гигантский репозиторий на песочницу ежедневно, используя rsync.
Здесь надо подводить итоги
Что я хотел этим всем сказать? То, что лично мне кажется, очень трудно автоматизировать процесс принятия решения о том, что бекап прошел успешно. Т.е.
успешно он, допустим, и прошел, а вот как не разворачивая этот бекап проверить, что в нем данные все правильные и актуальные? И, например, новые данные, спустя какое-то время не начнут ломать сам процесс бекапа? Причем, ошибки, приводящие к этому могут быть стары как мир:
- Человеческий фактор
- Ненадежность тулзов
- Ошибки в логике проверок
- проч.
Лично я не знаю ответы на вопросы озвученные выше. Если уважаемый хабр в курсе, прощу поделиться опытом. А пока что я уже очень давно считаю, что принцип «сделал и забыл», по крайней мере, в случае проведения бекапов, не работает. И советую разворачивать бекап целиком на отдельно стоящем тестовом сервере, если есть такая возможность (здесь мы убиваем двух зайцев ценой времени написания разворачиволки бекапа). Или же писать отдельный скрипт проверки целостности бекапов. Проверять нужно:
- дату создания бекапа
- размер файла
- изменение размера файла относительно предыдущего бекапа
- список файлов в бекапе (или хотя бы количество уникальных)
- … и всю эту информацию засылать аккумулирующим письмом в почту раз в сутки.
Спасибо за внимание.
UPD Спасибо за карму => перенес в блог «системной администрирование».
Источник: https://habr.com/post/94837/
Велосипедим. Резервное копирование Zabbix
Приветствую, товарищи. Вы видите перед собой пост о великом велосипедостроении! Как немногим известно, я являюсь страстным поклонником системы мониторинга Zabbix и всячески стараюсь нести доброту с его помощью для организации, где работаю на данный момент.
Однако, как многие open source решения, Zabbix требует от эксплуатирующего его админа некоторого постоянного развития — тут нет кнопочки “сделать заебись” и вам приходится долго и упорно учиться всему подряд — вы узнаете как устроен SNMP, научитесь писать скрипты на разных языках программирования, а может быть даже освоите подгружаемые модули на C, будете знать как устроена СУБД Zabbix, как с ней работать и оптимизировать под его задачи и прочее и прочее и прочее. И это хорошо. На самом деле, я не шучу. Весь этот проприетарный виндовый говнософт ужасно расслабляет ваши мозги, которым необходимо работать. Однако, это отдельная тема, а эта заметка посвящена написанию своего решения для резервного копирования простого инстанса Zabbix.
Сразу же, ссылка на репозиторий: https://github.com/asand3r/zbx_backup
Зачем?
Однако, хороший вопрос! Ведь уже давно написан скрипт, позволяющий снимать резервную копию с БД MySQL для Zabbix (https://raw.githubusercontent.com/maxhq/zabbix-backup/cc01e7b5db18c108870ffdc30de85c5f792e0ab2/zabbix-mysql-dump). Уверен, что и написан он очень умными людьми, пишущими на Bash гораздо дольше и больше меня, а главное — грамотнее.
Это ясно видно по коду. Однако, мне тоже нужно где-то учиться писать на Bash, а, как я считаю, нельзя на каких-то тупорылых примерах из книжек научиться писать на очередном языке, обязательно нужен какой-либо проект. Ага, это как с изучением иностранного языка — вам нужна практика. В общем-то, я уже очевидные вещи тут говорю…
Короче, решил я запилить такой скрипт самостоятельно.
Чуть-чуть о процессе
Как полагается, изначально скрипт 'zbx_backup' представлял собой сценарий из трех строчек, делающих ровно две вещи:
- Дамп БД MySQL в файл;
- Архивация этого файла в TAR с компрессией.
Версия 0.1, мать её (кстати, да, я из тех, кто начинает нумерацию версий софта с нуля)! Однако, как можно понять, вариант это хоть и рабочий, но если на этом остановиться, мы ничему не научимся.
Плюс, возникает вопрос — а что будет, если не существует каталога назначения? Или отсутствует указанная утилита компрессии? Или пользователь/пароль введены неверно? И еще тысяча-другая нюансов. Нам нужны проверки… Через некоторое время мы с гордостью запускаем версию 0.
1.1 и радуемся результатам её работы. Или не радуемся, если ошиблись. =)
Ага, оно работает, здорово. Хардкодим всё, что нужно и пихаем скрипт в крон. На следующий день идём проверять результат — архива нет. Твою мать, почему?! Ладно, нам нужно реализовать лог! Посидели, подумали сделали. Ага, однако мы мега-круты! Версия 0.1.2 увидела свет, открывайте шампанское! =)
Что же, в лог пишется всякая чепуха, это хорошо. Но мы замечаем, что при запуске нашего скрипта сервер Zabbix встает колом. Нехороший!
Надо что-то менять. Ясен пень, что виноват mysqldump! Блять, а как он работает? Я же просто нагуглил “как бекапить базу mysql” и всё… Ладно, идём читать. Попутно заказываем на Ozon.
ru пару книг по MySQL, читаем их тоже. Пока идёт процесс чтения, миримся с подвисанием и причесываем уже имеющийся код — комменты, проверки, коды выхода.
Ого, а скрипт-то уже тянет строк на 50 кода! Куда идти на собеседование в Яндекс?..
Проходит время, мы разобрались с бекапом MySQL, нашли вроде бы оптимальные опции, всё хорошо, но вдруг, из докладов на HighLoad'e, узнаем о существовании такой штуки как Percona XtraBackup. А что это? А зачем оно надо? Ого, как оно может! А для CentOS есть? Круто, хочу попробовать. Едрить, оно таблицы не брокирует! Всё, надо пихнуть в скрипт.
Ух! Так, что у нас там?.. Думаю, что это версия 0.2, определенно. Хм, а что если сделать так, чтобы пользователь сам мог выбирать утилиту для копирования БД?.. А как?.. Ладно, пусть будет переменная, потом подумаем. Возвращаем код с mysqldump, делаем простенький if-then-else. Яндекс идет нафиг, только Гугл! По-моему у меня развился нарциссизм…
Так-с, так-с, так-с, что тут у нас?.. Прозрение?
Именно. А что нужно восстановить в случае краха сервера? ОС, понятно. Доустановить софт, само собой.
Однако, все настройки сделанные в конфигах и все скрипты, положенные в папочки Zabbix'a будут потеряны навсегда. Так нельзя! Нужно срочно что-то делать! Добавим-ка в тот же архив ряд каталогов…
Ага, отлично, захардкодили. А что если их не окажется на месте? Или доступа не будет? Блин, крутим проверки.
Вот примерно так и происходит изучение языка, господа. =) Так и никак иначе. Читая книги, вы не получите практических знаний, всё это постигается только в реальных проектах. Еще лучше — покажите свой гениальный код кому-нибудь и, уверяю, вас обосрут с ног до головы.
Что? Bash? Это “башизмы”, непереносимо! А под ZSH работает? А вот тут не POSIX, закопать! Ага, а тут легко сломать, подставив 'rm -rf' вместо переменной. И так далее. Да, люди в ИТ часто злые мудаки, однако, на их критике можно поучиться.
И если вы не дурак, то прислушаетесь к ним, внесете изменения, выпустите новую версию. Потом еще одну. И еще. И еще… И вас уже не остановить — научитесь тюнить Vim, освоите Git (ведь если вы человек увлеченный, вам захочется покодить и дома).
А если ненароком у вас появятся пользователи? Пф, блять, да вы просто Бог! Ваш продукт кому-то нужен, это приятно. ^_^
Такие дела, друзья мои. =) Возвращаясь к моему проекту — я всё еще продолжаю активно его пилить, осваивать Bash и открывать для себя его возможности, коих, сука, ворох. Это вам не CMD в Windows, ага.
Добавились аргументы в которые вынесено 99% всех захардкоженных переменных, появился небольшой дебаг, запись в лог стала более информативной.
Да, закинул пробный вариант модуля для bash-completion, что значит у меня теперь есть функционал автодополнения аргументов, пусть и скудненький.
Итого
В итоге мы имеем еще один скрипт, позволяющий снять резервную копию с небольшого инстанса Zabbix. Полагаю, если вы мониторите им большую сеть, а сервер СУБД находится в кластере с NVPS > 5000 ед/сек, вы читаете мою заметку примерно так:
АХАХАХААХАахахахах! Сука, дебил!
Однако, если вы админ небольшой инсталляции и задались необходимостью резервного копирования, прошу на указанный выше Git-репозиторий. =) Удачи.
Источник: https://asand3r.livejournal.com/14088.html
Использование Zabbix для мониторинга: основные возможности. Практическое применение
Zabbix – это свободная (open-source) система для мониторинга состояния компьютерных сетей, серверов и различного оборудования. Фактически программа состоит из трех компонентов:
- Zabbix-сервер – это ядро системы (центральный процесс) программного обеспечения Zabbix. Используется для хранения и обработки всей информации, а также оповещает администраторов о возникающих проблемах.
- Zabbix-прокси – это процесс, который собирает данные с нескольких узлов в локальное хранилище. После этого, он передает всю информацию на сервер (единым пакетом).
- Zabbix-агент – это программа, устанавливаемая непосредственно на наблюдаемое устройство. Собирает всю информацию (о локальных ресурсах и приложениях), которая после передается на сервер.
Стоит отметить особенности Zabbix – программа поддерживает множество платформ (Linux, Mac OS, Windows) и доступна через веб-интерфейс. С его помощью вы можете получить доступ к данным мониторинга с любого ПК, но для этого стоит выполнить предварительную настройку на Zabbix-сервере.
Возможности Zabbix
Для сбора информации Zabbix использует системные вызовы, благодаря чему, влияние на производительность минимальное. Ознакомится с параметрами, которые мониторятся с помощью Zabbix можно в таблице.
| Категория | Детальные параметры |
| Базовые параметры | Нагрузка на CPUОбъем занятой оперативной памятиСвободное место на дискеСкорость работы накопителей (IOPS)Изменения определенных файловИнформация о сервере (время работы, имя) |
| Мониторинг комплектующих сервера. Для данного мониторинга используется интерфейс IPMI (либо его аналоги) | Температурные показатели (информация со всех установленных датчиков) и вольтаж комплектующихСкорость вращения вентиляторов |
| Информация о сетевом оборудовании | Уровень трафика (с разделением на download и upload)Состояние интерфейсов, а также информация о возникающих ошибках |
| Мониторинг служб | Получение информации о службах на сервере (например, о конкретных портах)Различные параметры служб MySQL Asterisk, Microsoft Exchange |
| Сертификаты | Срок службы сертификатов |
Это позволяет предотвратить возникающие проблемы до их наступления, а также точно определить “узкое” место в системе. Мониторинг осуществляется круглосуточно, что позволяет фиксировать все ошибки, независимо от времени их возникновения. Давайте разберемся, какие практические сценарии использования мониторинга Zabbix.
Пример 1. Непредвиденное отключение сервера
Возможная проблема
В ходе работы сервера накапливаются системные файлы. Это может привести к отключению сервера из-за переполнения системного диска C.
Решение
Мониторинг системы, был настроен на вывод предупреждения, если на диске доступно менее 5 Гб. Таким образом, администратор может предотвратить возникновение данного инцидента вновь, очистив диск С от ненужных файлов.
Пример 2. Некорректно работающее резервное копирование
Проблема
Бэкапы успешно выполнялись каждый день, однако, при очередном резервном копировании возникла ошибка. Настройки не изменялись.
Решение
Так как видимых причин проблемы нет (изменение настроек и т.д.), был установлен мониторинг. С его помощью выяснилось, что установленный сертификат неактуален – закончился срок действия. Сертификат был обновлен, после чего резервное копирование работает корректно.
Кроме того, Zabbix был настроен на отслеживание состояния сертифика. Как только срок его действия подходит к концу, администратор системы получал об этом уведомление.
Пример 3. Безопасность системы
Проблема
Несанкционированное добавление нового пользователя Linux, либо изменение прав уже существующих. Таким образом, злоумышленники могут получить доступ к всей системе и хранящейся информации.
Решение
Мониторинг файла passwd (в нем хранится информация о пользователях), сообщающий о его изменениях.
В случае добавления нового пользователя или изменения прав у существующих, администратор получает уведомление об этом.
Благодаря круглосуточному мониторингу, специалисты It-lite отреагируют на это в кратчайшие сроки и предпримут необходимые действия. Это позволит предотвратить несанкционированный доступ к системе в любое время суток.
Внедрение Zabbix
Как видим, Zabbix полезный инструмент, позволяющий не только найти причины ошибки, но и избежать ее повторения в будущем. Однако, для получения полной и корректной информации, следует выполнить его настройку.
Это технически сложный процесс, для которого не подходит универсальная инструкция. У специалистов It-lite большой опыт таких работ, благодаря чему они быстро и качественно выполнят внедрение мониторинга Zabbix.
При этом, они обязательно учитывают нюансы настраиваемой инфраструктуры.
Источник: https://www.it-lite.ru/blog/iaas/zabbix-dlya-monitoringa/
Резервное копирование Zabbix и восстановление БД из бэкапа
Бэкап Zabbix состоит из резервного копирования базы Zabbix и файлов конфигурации. С помощью Handy Backup можно автоматически создавать копию Zabbix в “горячем” или “холодном” режиме, а также выполнять восстановление Zabbix.Скачать Handy BackupВерсия 7.18.0 от 22 октября 2018164 MBВы можете создать расписание резервного копирования Zabbix для запуска задачи бэкапа с периодичностью от минут до месяцев. Вы также можете запускать другие программы до или после задачи, например, для остановки и перезапуска БД SQL при “холодном” бэкапе.Вы можете сжимать и/или шифровать ваши резервные копии Zabbix. Для экономии места и времени, вы можете также делать частичный бэкап Zabbix (дифференциальный или смешанный). Версии резервной копи Zabbix могут быть снабжены временными метками создания копии.Решение Handy Backup позволяет для Zabbix бэкап БД MySQL по сети, как в сетевых, так и в одиночных решениях. Возможно также копирование Zabbix под СУБД PostgreSQL. Все операции в программе выполняются под управлением графического интерфейса (GUI).Версия 7.18.0 от 22 октября 2018. 164 MBПрограмма резервного копирования Handy Backup. 7400 RUB за лицензию
Handy Backup Office ExpertРешение Office Expert для одного сервера или мощной рабочей станции предоставляет доступ ко всем плагинам СУБД и хранилищ, обеспечивая эффективный бэкап Zabbix. Бесплатная версия – 30 дней!Самый простой способ скопировать данные Zabbix — сохранить образ диска Windows с установленной Zabbix. Как правило, удобнее всё же создавать отдельную копию Zabbix; с помощью специализированной задачи Handy Backup сохранит только важные данные Zabbix! Создание резервной копии Zabbix под СУБД MySQLЧтобы создать задачу копирования Zabbix с использованием СУБД MySQL, пожалуйста, воспользуйтесь следующей инструкцией.
На заметку: Для MySQL и PostgreSQL вы можете подключиться к СУБД, находящейся на удалённом сервере!
Обычные скрипты бэкапа Zabbix размещают копию данных на локальном диске; Handy Backup предоставляет большой выбор способов хранения (например, копирование на Amazon S3). Программа включает следующие хранилища для резервной копии Zabbix:
|
Источник: https://www.handybackup.ru/zabbix-backup.shtml
Сравнение систем мониторинга Zabbix и PRTG network monitor
У такого подхода есть явный ряд минусов:Навыки программирования: несмотря на то, что большинство системных администраторов умеют писать сценарии на языках Perl, Python, Shell и Powershell, написание скрипта может стать первой «граблей», которую администратору (особенно молодому и неопытному) необходимо будет преодолеть.
Как результат – много времени уйдет на изучение языка сценариев.Сложности при развертывании: когда в зоне ответственности находится менее 10 серверов, перенести сценарий на каждую из машин и запустить их в работу по расписанию не составит труда.
Но что делать, если серверов 20? 50? 100?«Зоопарк» из технологий: если инфраструктура целиком построена на Linux-системах или на системах семейства Microsoft Windows, это одно.
Но если в компании есть и домен-контроллер, реализованный на Microsoft Windows Server, файловое хранилище на Freebsd и почтовый сервер Postfix на CentOS, то администратор вынужден разрабатывать разные сценарии под конкретную ОС, решающие одну и ту же задачу.
Сложности в решении задачи мониторинга сподвигли к созданию отдельных мониторинговых систем, как вендорных решений (например Oracle Enterprise Manager), так и open source решений (Zabbix) и коммерческих решений (PRTG, Nagios).В этой статье мы рассмотрим Zabbix 2.2 и PRTG Network Monitor 14.
3 с точки зрения возможностей систем и сложностей в установке, настройке и пользования.Краткий обзор продуктов:Zabbix является open source enterprise-решением (согласно информации на оф.
сайте), которое может производить комплексный мониторинг инфраструктуры (серверы, сетевые устройства и виртуальные машины), визуализировать полученную информацию в графики, следить за нагрузкой и производительностью оборудования с использованием собственных агентов (которые поддерживаются практически всеми операционными системами).
Решение PRTG ориентировано под мониторинг сети (сетевые устройства, интерфейсы, каналы передачи данных). Решение не требует установки агентов на объекты мониторинга и использует стандартные протоколы и технологии ICMP, SNMP, Packet Sniffing, NetFlow и т.д. В PRTG часто используется понятие «сенсор».
Сенсором в данном случае выступает сетевая служба, находящаяся на разных уровнях модели OSI (может мониториться порт на оборудовании или работа HTTP, POP/SMTP).Обе системы мониторинга имеют возможность отправлять предупреждения об инцидентах через электронную почту или SMS, могут работать как через http, так и через https.
Это очень важное свойство, если систему мониторинга «выпускать» в интернет.Сразу можно сказать, что в отличие от Zabbix, который ориентирован под всю инфраструктуру в целом, PRTG разработан для мониторинга сетей и всего, что с ними связано.Для чистоты эксперимента, я буду использовать оба решения под одну задачу: мониторинг сети и серверов.ТребованияДля начала хотелось бы учесть, что Zabbix, как продукт свободного программного обеспечения, целиком бесплатен и не требует оплаты за свой функционал. Что касается PRTG, то на сайте продукта предлагается два варианта (не считая бесплатного пробного периода): платная лицензия и бесплатная с ограничением на 10 сенсоров.Обратимся к системным требованиям обоих продуктов и сравним их.
Согласно официальным сайтам продуктов понять приблизительные требования сложно. В этом вы можете убедиться сами, пройдя по ссылкам:www.zabbix.com/requirements.php и www.paessler.com/prtg/requirements
ZabbixПо решению Zabbix в системных требованиях указаны лишь поддерживаемые операционные системы, из чего сложно сделать вывод, сколько ядер и оперативной памяти будет необходимо выделить виртуальной машине, или какой мощности сервер необходимо закупить.На сайте продукта также указано, что для работы Zabbix необходимы Apache, MySQL, PHP, так что требования необходимо также определять из необходимых ресурсов для веб-сервера Apache и СУБД MySQL. Однако, в документации по установке указаны приблизительные требования под количество объектов мониторинга.PRTGНу а по решению PRTG идет (цитата): «A PC, server or virtual machine with roughly the CPU performance of an average PC built in the year 2007 or better and minimum 1024 MB RAM memory.»Но тем не менее по PRTG есть подробное описание системных требований, к которому можно обратиться. Из него видно, что:Для ядра системы мониторинга подойдет любая ОС семейства Microsoft Windows старше Windows 7 / Windows Server 2008;Процессор для среднего PC, выпущенного в 2007 году, может с легкостью мониторить 1000 сенсоров;Оперативная память – минимум 1024 Мб. На каждый сенсор потребуется 150 Кб.;Жёсткий диск – 200 Кб на сенсор в день;Стабильное интернет-соединение.Я буду устанавливать оба решения на виртуальной машине на основе Oracle Virtual Box со следующими параметрами: 1 CPU, 2048 Memory, 20 Gb HDD VDI.Для Zabbix будет использован CentOS версии 6.5 x86_64, для PRTG – Windows 7 Professional 64 bitУстановкаZabbixДля установки, как уже говорилось ранее, необходим LAMP-сервер. Пакеты ставятся из стандартных репозиториев CentOS, пакет Zabbix также берется с оф. репозитория.Не сказать, что установка Zabbix проста, но уверенный linux-администратор без особого труда установит себе экземпляр. Стоит отдельно поблагодарить технических авторов проекта за подробную инструкцию по установке – благодаря ей установка идет пошагово легко. Сначала подключается репозиторий Zabbix, откуда можно взять необходимые пакеты даже для LAMP, конфигурируется БД MySQL, редактируется конфигурационный файл сервера Zabbix.Установка велась через SSH базовыми командами yum и rpm. Вся установка решения с конфигурацией БД MySQL, параметрами системы мониторинга и веб-сервера заняла у меня где-то 30 минут.После этого я обнаружил у себя в браузере вожделенное окно:Дополнительное удобство при установке дает сама веб-морда приложения – если какие-то настройки не были выполнены, система сама об этом сообщит.PRTG network monitorНа сайте решения указано, что установка проста и занимает 2 минуты. Учитывая специфику установки приложений в среде MS Windows, сомневаться в простоте не придется. Но займет ли это действительно 2 минуты?Скачав дистрибутив с оф. сайта и получив лицензионный ключ, я приступил к установке. Здесь стоит добавить, что разработчик не соврал. После нажатия Next – Next – Next — ввода лицензии – Next, прошло действительно около 2 минут, после чего система объявила мне, что у меня слишком старый браузер.После перезагрузки PRTG предложил просканировать мою сеть с использованием GURU.Давайте попробуем.GURU действительно начал «бегать» по сети, изучая все ее сегменты. После всех настроек на экране высветился дашбордРабота с мониторингом.ZabbixКак видно, многое еще необходимо настроить. По умолчанию Zabbix мониторит сам себя, все остальное может быть добавлено как вручную, так и с использованием autodiscovery, но для этого необходимо ставить агентов на объекты мониторинга, хотя можно мониторить и с помощью SNMP. Агенты ставятся без лишних проблем (либо через репозиторий для linux, либо с оф. сайта для windows). В конфигурации выставляется адрес сервера Zabbix, после чего приступаем к добавлению хоста:Окно добавления объекта мониторинга.В настройке предлагается настроить интерфейс агента или производить мониторинг с использованием других протоколов – выбор остается за администратором, но следует учитывать, что использование агента снижате нагрузку на сам сервер Zabbix.Zabbix богат стандартным набором шаблонов мониторинга. При добавлении объекта к нему можно привязать необходимые шаблоны и запустить мониторинг.Отдельно стоит обратить внимание на особенности Zabbix:Шаблоны – помимо стандартных, можно добавлять (и разработать) свои для задач, которые не решаемы «из коробки»;Сценарии – можно выполнять команды из сценариев на определенном хосте;Карта – в Zabbix существует возможность «нарисовать» сетевую карту для визуализации зависимостей оборудования друг от друга;IT-сервисы – администратор строит зависимость одного объекта от другого, что позволяет проактивно устранить проблему, пока не поздно, или отследить проблемный узел.В целом Zabbix полностью оправдывает звание enterprise-продукта: богатый набор функций «из коробки» и возможность настройки любого шаблона или сценария превращают его в очень мощный инструмент для инженера.PRTG network monitorПри входе в систему пользователь сразу увидит стандартный дашборд с древовидной структурой, в котором по умолчанию будет добавлен хост самой системы мониторинга. По желанию отображение объектом можно изменить.Вот так будет выглядеть PRTG, если стилизовать его в виде Oracle Enterprise ManagerКак определяются размеры мне пока не ясно, но подозреваю, что на размер прямоугольника влияет количество сенсоров на объект. Зеленым помечаются объекты, с которыми все ОК, синим – объекты на паузе, красным – объекты в состоянии down. Белым обозначаются ненастроенные устройства.А вот здесь видны огрехи шрифтов и верстки:Да, к сожалению именно так и отображается текст, если объекты показывать в виде окружности.Впрочем, администратор сам выберет удобный для него интерфейс. Мы же рассмотрим возможности мониторинга.В отличие от Zabbix, PRTG не нуждается в установке дополнительных агентов. Базовый функционал реализуется через использование нативных библиотек для работы с протоколами ICMP, SNMP и другими, однако это не отменяет возможности использования сторонних библиотек для работы со внешним оборудованием (напр. Netping).Логическая иерархия здесь стандартная: есть группы объектов, есть сенсоры, есть объекты. Благодаря возможностям autodiscovery, можно добавить группу с определенным пулом IP-адресов, и PRTG самостоятельно просканирует все адреса из пула, настроив на них сенсоры.Объекты можно добавлять вручную, без использования нативных средств PRTG – это обычно необходимо для случаев использования нестандартных портов либо других способов обеспечения безопасности объектов. Объекту назначается необходимая группа, выставляются индивидуальные сенсоры, права доступа.Доступы пользователей PRTG работают по принципу read, write, full. Особенностью прав write и full является то, что права write могут быть необходимы разработчикам библиотек (например, библиотек SNMP), которым возможно необязательно видеть объекты мониторинга, а права full необходимы для администраторов системы, чтобы добавлять/удалять/редактировать объекты мониторинга и настраивать на них сенсоры. Отдельного внимания заслуживает редактор карт PRTG. Здесь администратор может нарисовать сетевую карты с взаимосвязями объектов.Все взаимосвязи делаются вручную, но подобный вид отображения удобен, когда необходимо показывать сетевую инфраструктуру и надо понимать зависимость одного узла от другого.Также присутствует мониторинг загруженности интернет-канала с вполне читаемым графиком.В целом PRTG способен не только мониторить сетевую доступность, но и нагрузку на оборудование. Среди сенсоров также присутствуют средства для мониторинга доступности СУБД, веб-серверов и серверов приложений.Использование систем мониторинга с оборудованием Netping
Но как и любому инженеру, отвечающему за инфраструктуру, мне важно понимать, в каком состоянии находится моя серверная. Здесь я воспользуюсь любезно предоставленным компанией Netping устройством Uniping Server Solution v3/SMS.
Вкратце о «железке»: 1-юнитовый Uniping получает информацию с датчиков дыма, влажности, температуры и т.д. и способен передавать ее через Ethernet-интерфес системам мониторинга.
Также внутри имеется GSM модем для SMS-оповещения, реле для управления локальной индикацией и сигнализацией, возможность подключения к WiFi сети для беспроводных датчиков.
Как подружить Uniping с Zabbix
На сайте Netping существует инструкция по добавлению оборудования Netping в мониторинг Zabbix: www.netping.ru/view.aspx?id=54
Несмотря на то, что версии Zabbix и оборудование Netping у меня и в статье разнятся, это не мешает произвести настройку.В отличие от стандартного добавления объекта с использованием агента Zabbix, с Netping придется использовать протокол SNMP v1 для сбора данных с датчиков.По итогам настройки я получаю информацию по температурным датчикам, которые могу наблюдать на графике.
Данные полученные из шаблона с сайта Netping:График температуры на основании одного из датчиков.Зеленая полоска справа сверху передает нам текущую температуру с датчика. Если это серверная, то 27 градусов многовато. Впрочем это уже задача техобслуживания – обеспечить необходимую температуру. Мы же рассмотрели совместную работу Zabbix и Netping.
Как подружить Uniping c PRTG network monitor
На сайте производителя подробно описано, как получать данные с Uniping на мониторинг PRTG. Конечно инструкция написана для более старой версии, настроить последнюю версию PRTG не составило особого труда. С сайта производителя скачивается библиотека SNMP для PRTG и добавляется к уже имеющимся.
Дальше подключение идет по инструкции с сайта: www.netping.ru/view.aspx?id=120
На выходе мы получаем полную информацию с датчика:Полная информация по температуре, влажности и наличии питания в серверной – как раз то, что мне необходимо знать об обстановке внутри серверной.
Достоинства/НедостаткиZabbix+-Является полностью бесплатным продуктом Пользователь без администраторских прав не может создать комплексный экран (screen)Существует возможность создания персональных сценариев и шаблонов Требует установку apache, mysql, php. Работает только в *nix-подобных системах.
Есть возможность мониторинга внутренних процессов на объектахPRTG Network Monitor+-Просто в установке. Пресловутые «2 минуты» оказались правдой Является платным продуктомУдобен в работе, добавление сенсоров и объектов реализовано на интуитивном уровне Работает только в среде Microsoft Windows, что увеличивает стоимость решения на одну лицензию.
Использует нативные средства – нет необходимости установки дополнительного ПО на объектах мониторингаНа мой взгляд, оба продукта имеют право на жизнь и могут быть использованы как в мелких инфраструктурах (не более 10 серверов, не более 100 рабочих мест), так и в крупных (более 2000 рабочий мест, более 200 серверов).
Если бы моя инфраструктура была построена целиком на экосистеме Microsoft, я бы использовал PRTG: несмотря на то, что продукт платный, он легко впишется в экосистему, а наличие приложений для смартфона позволило мне приглядывать за моей зоной ответственности даже вне офиса.
Однако, если передо мной стоит задача комплексного мониторинга не только инфраструктуры, но и информационных систем (таких на СУБД, сервера приложения, java-машины и прочее), я выберу Zabbix, как мощное и, что немаловажно, бесплатное решение.
Очевидным плюсом для обоих систем является возможность работы со сторониим оборудованием для сбора информации с датчиков. Очевидный плюс продуктам Netping, которые легко интегрируются с описанными мною решениями.
Источник: http://www.saimoniks.com/network/sravnenie-sistem-monitoringa-zabbix-i-prtg-network-monitor
Загрузка...
