Моя команда пытается решить проблему мониторинга, когда дело доходит до резервного копирования.
Резервное копирование работает нормально. Наша текущая задача - отслеживать эти резервные копии, чтобы они действительно делать случиться.
Мы можем отправить письмо в случае неудачи и успеха. Теперь мы хотим проверить наличие этих писем и
Таким образом, мы узнаем, не удалось ли выполнить резервное копирование или отправить письмо не удалось. Вот почему мы также отправляем сообщение об успешном завершении, чтобы подтвердить, что оно действительно отправлено.
Я полагаю, что эта идея чем-то похожа на сердцебиение, которое на самом деле проверяется вместо пассивного ожидания сбоев.
Какой инструмент может нам помочь?
Я подозреваю, что такой инструмент позволяет нам вводить ожидания, которые должны произойти, например, письмо должно быть получено в последний день, будь то успех или неудача.
Инструмент был бы еще лучше, если бы он мог напрямую переходить к диску и проверять наличие файлов резервных копий, но мы хотели бы поддержать почтовый ящик, а также в настоящее время другие системы сообщают об этом.
Проверка свежести Nagios.
http://nagios.sourceforge.net/docs/3_0/freshness.html
Примером службы, которая может требовать проверки актуальности, может быть служба, сообщающая о состоянии ваших заданий ночного резервного копирования. Возможно, у вас есть внешний сценарий, который отправляет результаты задания резервного копирования в Nagios после завершения резервного копирования. В этом случае все проверки / результаты для службы предоставляются внешним приложением с использованием пассивных проверок. Чтобы гарантировать, что состояние задания резервного копирования будет сообщаться каждый день, вы можете включить проверку актуальности для службы. Если внешний сценарий не отправляет результаты задания резервного копирования, вы можете заставить Nagios подделать критический результат, выполнив что-то вроде этого ...
Вот как может выглядеть определение службы (некоторые обязательные параметры опущены) ...
define service{
host_name backup-server
service_description ArcServe Backup Job
active_checks_enabled 0 ; active checks are NOT enabled
passive_checks_enabled 1 ; passive checks are enabled (this is how results are reported)
check_freshness 1
freshness_threshold 93600 ; 26 hour threshold, since backups may not always finish at the same time
check_command no-backup-report ; this command is run only if the service results are "stale"
...other options...
}
Обратите внимание, что для службы отключены активные проверки. Это связано с тем, что результаты для службы создаются только внешним приложением с использованием пассивных проверок. Проверка свежести включена, и порог свежести установлен на 26 часов. Это немного больше, чем 24 часа, потому что задания резервного копирования иногда выполняются с опозданием изо дня в день (в зависимости от объема данных для резервного копирования, наличия сетевого трафика и т. Д.). Команда no-backup-report выполняется только в том случае, если результаты службы определены как устаревшие. Определение команды no-backup-report может выглядеть так ...
Мы согласны с тем, что лучшее решение - это то, с которым вы доверяете работать каждый раз, и которое предупреждает вас только тогда, когда вам нужно что-то исправить. Оповещение об успехе вызывает перегрузку электронной почты системного администратора и становится неприемлемым, поскольку у вас появляется больше систем и системных администраторов.
Инструмент был бы даже лучше, если бы он мог напрямую переходить к диску и проверять наличие файлов резервных копий.
Да, вы уже знаете правильное решение. Так обычно и делается.
Что касается проблем с электронной почтой, возможно, вы могли бы вникнуть в то, что там происходит, и исправить их отдельно, чтобы вы не пытались исправить неработающую электронную почту с помощью системы мониторинга резервных копий.
Для меня это звучит немного странно;
Таким образом, вы получите электронное письмо с сообщением, было ли резервное копирование успешным или нет. Теперь вы хотите проверить, получаете ли вы электронное письмо, и получать предупреждение, если резервное копирование было неудачным или даже если оно было успешным, но письмо не пришло.
Мне кажется, вам следует отказаться от электронной почты и просто использовать решение для прямого мониторинга. Вы можете написать сценарий, я видел это много раз раньше. Однако как бы вы предупредили вас по электронной почте? У вас уже есть решение для мониторинга, которое делает это!
Проблема здесь, кажется, в том, что вам нужно отслеживать, пришло ли письмо или нет, поэтому вы подключаете систему мониторинга к своей системе мониторинга. Если электронные письма ненадежны, не сообщайте об успешном выполнении резервного копирования по электронной почте.
Трудно комментировать рекомендацию, не зная, что вы создаете резервную копию и как, но мне кажется, что у вас здесь запутан порядок / логика ситуации.
Это опасно близко к вопросу о покупках, но я все равно укушу.
Я часто использую NAGIOS, чтобы делать такие вещи (потому что я все равно много использую NAGIOS, поэтому хорошо, что все мои статусы и уведомления находятся в одном месте). У меня есть отчеты агентов об использовании send_nsca, а службы настроены на УСТАРЕВАНИЕ и предупреждение, если они не получают обновлений, скажем, в течение 36 часов.
Службы, обнаруживающие сбой, могут сообщить об этом с помощью send_nsca; те, кто уверен, что добились успеха, могут сообщить об этом. Сервисы, которые терпят неудачу настолько сильно, что ничего не сообщают, попадают в приведенный выше тест на свежесть.