Назад | Перейти на главную страницу

Что такое надежный процесс разработки системы мониторинга?

Краткая версия: у меня есть гетерогенная среда из ~ 400 хостов, использующих Groundwork / Nagios для мониторинга. Текущие проверки, группы хостов и сервисные группы были объединены органическим, разовым образом. Мне поручено по сути восстановить настройку мониторинга.

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

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

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

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

То, что следует ниже, ни в коем случае не является исчерпывающим или полным, но очень похоже на мой метод настройки мониторинга и должно помочь вам двигаться в правильном направлении:


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

    1. Некоторые из этих вещей обычны
      Многие из них можно скопировать из сообщения Кайла, поэтому я не буду перечислять их, но вы хотите получать уведомления о ПРЕДВАРИТЕЛЬНЫЙ ОТКАЗ условия - например, ОДИН диск в RAID5 вышел из строя - замените его сейчас, чтобы избежать простоя в дальнейшем.
    2. Другие зависят от вашей инфраструктуры / дизайна и включают зависимости от других сервисов.
      Если вы используете веб-сайт с поддержкой базы данных, и база данных не работает, ваш сайт не будет работать
       
  2. Взгляните на зависимости и постройте дерево зависимостей.
    (В центре обработки данных вы можете управлять этим, насколько хотите: на моей последней работе мы были хостинговой компанией, и наша система мониторинга взаимодействовала с нашими системами ИБП, генераторов и охлаждения, чтобы держать нас в курсе их статуса)

  3. Вооружившись всей этой информацией, вы можете решить, что можно отслеживать в упреждающем режиме, а на что можно только реагировать.
    (например, «Сетевой кабель (-а) выдернут», любой сервер выйдет из строя, но стоит ли следить за состоянием порта коммутатора, или вы хотите, чтобы это была ситуация «Он не работает, я должен пойти посмотреть на это»?) .

Остается только выбрать программное обеспечение для мониторинга для реализации вашего видения. Этот выбор должен основываться на том, какой пакет позволяет вам отслеживать все (или большую часть) вашего идеального списка, и реально учитывает разницу в ценах между пакетами.