Инструмент для мониторинга успеха или неудачи в течение заданного периода времени

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

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

Мы можем отправить письмо в случае неудачи и успеха. Теперь мы хотим проверить эти письма и

  1. предупредить, если почта сообщает об ошибке
  2. оповещение, если сообщение об успешном получении не было получено, скажем, за день (будет настроено)

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

Я полагаю, что эта идея чем-то напоминает сердцебиение, которое на самом деле проверяется, а не пассивно ждет неудачи.

Какой инструмент может помочь нам?

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

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

Источник

4 ответа

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

Инструмент будет еще лучше, если он сможет напрямую перейти на диск и проверить наличие файлов резервной копии

Да, вы уже знаете правильное решение. Так обычно и делается.

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

Источник

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и службы настроены на STALE и оповещение, если они не получают обновлений, скажем, в течение 36 часов.

Службы, которые обнаруживают сбой, могут сообщить о них send_nsca; те, кто уверен, что преуспели, могут сообщить об этом. Службы, которые так плохо работают, что ничего не сообщают, попадают в тест свежести

Источник

Это звучит немного странно для меня;

Таким образом, вы получите электронное письмо, чтобы сказать, было ли резервное копирование успешным или нет. Теперь вы хотите проверить, получили ли вы электронное письмо, и получать оповещения, если резервное копирование было неудачным или даже успешным, но письмо не пришло.

Похоже, вы должны оставить часть электронной почты и просто использовать решение для прямого мониторинга. Вы могли бы написать это, я видел это много раз раньше. Однако, как бы вы предупредили вас об этом по электронной почте? У вас уже есть решение для мониторинга, которое делает это!

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

Трудно комментировать рекомендацию, не зная, что вы резервируете или как, но мне кажется, что у вас есть порядок / логика ситуации, запутанной здесь.

Источник
Другие вопросы по тегам