Лучший инструмент для мониторинга резервных копий и т. Д. И отслеживания статистики по этим данным
Я провел некоторые исследования nagios, opennms и zenoss, но не уверен, что нашел то, что искал.
Главная движущая сила для меня сейчас - возможность контролировать резервные копии. Это включает в себя mysql, mssql и, в конечном итоге, некоторые резервные копии файловой системы.
У нас есть инструмент, который оборачивает процесс резервного копирования для этих различных систем и собирает статистику. Итак, такие предметы, как:
- количество резервных копий баз данных
- размер файла резервной копии в дБ
- размер сжатого файла резервной копии в дБ
- время сделать резервную копию
- время архивировать файл
Я хочу иметь возможность A) получать уведомления, если задания не выполняются в соответствии с расписанием B) иметь возможность устанавливать пороговые значения для статистики, которые будут вызывать уведомления C) Я хочу иметь возможность отслеживать и составлять график статистики
Я планирую отправить эту информацию в приложение мониторинга через HTTP POST. Или приложение мониторинга может также извлечь его из файла журнала.
Тем не менее, у нас будут другие процессы с другой "произвольной" (с точки зрения системы мониторинга) статикой, которую нужно отслеживать и отслеживать, поэтому гибкость очень важна.
Инструмент или инструменты также должны иметь возможность осуществлять общий мониторинг и отслеживание сетевых интерфейсов, нагрузки на сервер и т. Д. После того, как мы запустим мониторинг резервного копирования, мы захотим включить и эти элементы.
Благодарю.
Продолжение:
Я решил попробовать следующее в данном порядке:
- Zabbix: казался скорее "универсальным магазином", чем другие, и его было легко установить в Ubuntu Lucid RC
- opsview
- Nagios с Nagvis, pnp4nagios, nagiosgraph
- плагин cacti w/ npc
- Мунин: немного шрамы от простоты, но это может оказаться благословением в долгосрочной перспективе
Отправлю ответ, как только я приму решение, может пройти некоторое время, пока это не произойдет.
7 ответов
Это должно быть довольно легко настроить с помощью zabbix.
Настроить пользовательские (и очень мощные) пороги очень просто - вы можете написать любое выражение, которое вам нравится, поэтому возможно что-то вроде "уведомить меня, если более 3 из этих 5 серверов не выполнили успешное резервное копирование". Вы также можете использовать 6 различных уровней серьезности и эскалаций для достижения гибких уведомлений и предупреждений.
zabbix имеет встроенные возможности хранения и визуализации данных - все данные хранятся в базе данных, и для построения одной метрики вам не нужна никакая конфигурация - вы просто получаете график для нее "бесплатно". для длительного хранения и трендов рассчитываются средние значения за один час.
Что касается получения ваших данных о резервных копиях в zabbix, существует множество возможностей. вы можете читать его из файлов, вы можете запускать пользовательские команды, вы можете выгружать его с контролируемой машины, используя утилиту командной строки zabbix_sender... и может быть еще несколько возможных подходов.
Расширение легко - любая пользовательская команда, которая возвращает данные, может быть использована для сбора, хранения и визуализации этих данных.
Конечно, возможен общий мониторинг операционных систем, приложений, устройств snmp и ipmi и так далее.
Вместо того, чтобы писать собственное решение для мониторинга, я настоятельно рекомендую вам использовать существующий инструмент, чтобы все основные функции мониторинга и оповещения уже были реализованы. Если вы выберете Nagios, вы получите базовый мониторинг серверных и сетевых ресурсов бесплатно, и следующие плагины должны дать вам большую часть остального, что вам нужно:
check_file_ages_in_dirs скажет вам, существуют ли файлы резервных копий; вот сообщение в блоге, которое я написал с некоторыми основными примерами.
check_file может отслеживать размер файла и его содержимое (используя регулярные выражения), поэтому вы можете выводить резервную копию статистики в файл и отслеживать ее.
Единственное, что вы не получите от Nagios - это тренды и графики; Я рекомендую взглянуть на Munin для этого, так как его легко настроить, и, как и в Nagios, у него есть стопки подключаемых плагинов.
nagios может делать тренды, но вам нужно вывести perfdata ( http://nagios.sourceforge.net/docs/1_0/perfdata.html) в ваш плагин. Если вы используете pnp4nagios http://docs.pnp4nagios.org/pnp-0.4/start то все будет в порядке для вас.
Я обнаружил, что использовать opsview http://www.opsview.org/ гораздо проще, чем настраивать nagios и pnp4nagios. Особенно, если вы являетесь единственным опытным администратором Linux на работе. Opsview - это nagios с отличным веб-интерфейсом, который позволяет выполнять практически все действия из веб-браузера. Поскольку это nagios, вы можете использовать все плагины nagios, которые вы использовали в прошлом. Отличный инструмент.
Я рекомендую OpenNMS. Пакет полностью с открытым исходным кодом, активно поддерживается и регулярно совершенствуется. Для справки я нашел в их вики информацию о конфигурации для мониторинга Symantec Backup Exec.
С их сайта..
OpenNMS является первой в мире платформой управления сетью уровня предприятия, разработанной в рамках модели с открытым исходным кодом. Он состоит из проекта с открытым исходным кодом, поддерживаемого сообществом, а также организации коммерческих услуг, обучения и поддержки.
Раскрытие информации: у меня нет здесь никакого коммерческого интереса, но владелец OpenNMS Group, "организации коммерческих услуг, обучения и поддержки", упомянутой выше, является моим другом.
выполнение
резервные копии организованы backupninja. я использую его просто как обертку для моих скриптов bash - чтобы иметь единый журнал резервного копирования. каждый скрипт начинается с
function handle {
echo Error
error problem occured
}
set -e
trap handle ERR
поэтому я получаю сообщение об ошибке в журналах всякий раз, когда любая из команд [например, mysqldump или rsync ] не выполняется.
все резервные копии заканчиваются в репозитории rdiff, поэтому у меня есть n дней приращений.
все резервные копии передаются с помощью rsync на центральный сервер хранения.
на сервере хранения все резервные копии проверяются ежедневно, и после успешной проверки данных на локальном диске они копируются на внешний USB-накопитель.
проверка
На всех серверах backupninja.log контролируется nagios. я проверяю, содержат ли они только сообщения DEBUG и INFO. все остальное вызывает тревогу.
каждая резервная копия "касается" тестового файла, наличие и свежесть которого отслеживается на центральном сервере хранилища резервных копий с помощью nagios.
Кроме того, более критические дампы SQL проверяются на их размер [не только свежесть] и полноту [например, в конце дампов MySQL, я ожидаю, что новая отметка времени в
- Дамп завершен 2010-04-22 23:21:02
Все архивы rdiff проверяются ежедневно перед синхронизацией данных на USB-накопителе, а затем снова после их синхронизации. так что даже если ночная передача будет прервана, у меня будет постоянный репозиторий только на USB-диске. результат проверки заносится в файл, содержание и свежесть которого проверяется нагиосом.
USB-диски вращаются еженедельно и хранятся в автономном режиме, на всякий случай. это может быть излишним для больших объемов данных, но отлично работает для ~300 ГБ медленно меняющихся файлов / дампов.
тенденции
я использую простой пользовательский плагин munin, чтобы построить размер diff/data для каждого репозитория rdiff.
Время выполнения может быть проверено в журналах резервного копирования, но пока я не беспокоюсь об этом.
Это можно легко сделать с помощью Circonus ( http://circonus.com/). Мы регулярно импортируем такие метрики с Resmon XML DTD.