Географически распределенные, отказоустойчивые и «интеллектуальные» системы мониторинга приложений / хостов


12

Привет,

Я хотел бы спросить мнение и мнение коллектива о распределенных системах мониторинга, что вы используете и что вы знаете о том, что может пометить мои флажки?

Требования довольно сложны;

  • Нет единой точки отказа. В самом деле. Я очень серьезно! Необходимо иметь возможность терпеть отказ одного / нескольких узлов, как «главного», так и «рабочего», и вы можете предположить, что ни в одном месте мониторинга («узле») нет нескольких узлов или они находятся в одной сети. Поэтому это, вероятно, исключает традиционные методы HA, такие как DRBD или Keepalive.

  • Распределенная логика, я хотел бы развернуть более 5 узлов в нескольких сетях, в нескольких центрах обработки данных и на нескольких континентах. Я хочу, чтобы «птичий глаз» смотрел на мою сеть и приложения с точки зрения моих клиентов, чтобы бонусные баллы за логику мониторинга не застряли, когда у вас более 50 узлов или даже более 500 узлов.

  • Требуется уметь обрабатывать довольно разумное количество проверок хоста / сервиса, например, Nagios, для приблизительных показателей - 1500-2500 хостов и 30 сервисов на хост. Было бы неплохо, если бы добавление большего количества узлов мониторинга позволило бы вам масштабироваться относительно линейно, возможно, через 5 лет я мог бы отслеживать 5000 хостов и 40 сервисов на хост! В дополнение к моей заметке о «распределенной логике» было бы неплохо сказать:

    • В обычных обстоятельствах эти проверки должны выполняться на $ n или n% узлов мониторинга.
    • Если обнаружен сбой, запустите проверки на других $ n или n% узлов, сопоставьте результаты и затем используйте их, чтобы решить, были ли выполнены критерии для выдачи предупреждения.
  • Графики и управление дружественными функциями. Нам нужно отслеживать наши SLA, и знание того, работают ли наши «высокодоступные» приложения 24x7, является несколько полезным. В идеале предлагаемое решение должно создавать отчеты "из коробки" с минимальными ошибками.

  • Должен иметь надежную систему API или плагинов для разработки индивидуальных проверок.

  • Нужно быть осторожным с оповещениями. Я не хочу обязательно знать (через SMS, в 3 часа ночи!), Что один узел мониторинга считает, что мой основной маршрутизатор не работает. Я действительно хочу знать, согласен ли определенный процент из них , что происходит что-то напуганное;) По сути, я говорю здесь о логике «кворума» или применении здравомыслия к распределенному безумию!

Я готов рассмотреть как коммерческие варианты, так и варианты с открытым исходным кодом, хотя я бы предпочел держаться подальше от программного обеспечения, стоившего миллионы фунтов стерлингов :-) Я также готов согласиться, что не может быть ничего, что помечало бы все эти рамки, но хотел спросить у коллектива, что.

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

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

Рады уточнить любые необходимые вопросы. Ура ребята и девчонки :-)


2
Это действительно странно, я собирался задать аналогичный вопрос. На этой неделе у нас были жалобы клиентов на перебои в работе сайта, но только из определенных мест. Наши системы оповещения не обнаружили этих проблем. Мы связались с нашим провайдером, и они подтвердили, что у некоторых были проблемы с позвоночником. Так что я тоже заинтересован в решении. Благодарность!
splattne

И каково было окончательное решение?
2012 г.

Ответы:


4

не ответ на самом деле, но некоторые указатели:

  • Обязательно посмотрите презентацию о nagios @ goldman sachs . они столкнулись с проблемами, о которых вы упомянули - избыточность, масштабируемость: тысячи хостов, а также автоматическое создание конфигурации.

  • у меня была избыточная установка nagios, но в гораздо меньшем масштабе - 80 серверов, всего ~ 1 тыс. сервисов. один выделенный ведущий сервер, один подчиненный сервер, который получает конфигурацию с главного устройства через равные промежутки времени несколько раз в день. оба сервера контролировали одни и те же машины, у них была перекрестная проверка работоспособности между собой. я использовал nagios главным образом в качестве среды для вызова пользовательских проверок, специфичных для продукта [куча заданий cron, выполняющих сценарии, выполняющие «искусственное управление потоком», результаты регистрируются в sql, модуль подключаемых модулей nrpe проверяет их успешное / неудачное выполнение за последние x минут]. все работало очень хорошо.

  • ваша логика кворума звучит хорошо - немного похоже на мои «искусственные потоки» - в основном продолжайте, воплощайте себя; -]. и имейте nrpe, просто проверьте какой-нибудь флаг [или sql db с timestamp-status], как дела.

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

ответить на несколько вопросов:

  • в моем случае отслеживаемая среда была типичной установкой master-slave [первичный sql или сервер приложений + горячий резерв], без master-master.
  • В моей настройке использовался «человеческий фактор фильтрации» - группа распознавателей, которая была «резервной копией» для уведомления смс. уже была оплачиваемая группа техников, у которых по другим причинам были смены 24/5, они получили «проверку почты nagios» в качестве дополнительной задачи, не оказывая на них слишком большой нагрузки. и они отвечают за то, чтобы db-admins / it-ops / app-admins действительно поднимались и решали проблемы; -]
  • Я слышал много хорошего о zabbix - для оповещения и составления графиков трендов, но никогда не использовал его. для меня Мунин делает свое дело, я взломал простой плагин nagios, проверяющий, есть ли в списке серверов «любой красный» [критический] цвет - просто дополнительная проверка. Вы также можете прочитать значения из run-файлов munin, чтобы уменьшить количество запросов, отправляемых на контролируемую машину.

1
@astinus - хорошо для толковых предупреждений я использовал собственный скрипт уведомлений. вместо того, чтобы полагаться на уведомления nagios по почте / пейджеру, я сохранял сообщение в fifo que и имел потребителя, который отправлял сообщение на основе пользовательской логики [на основе довольно гибкого расписания вызовов и т. д.], кроме того, было некоторое ограничение на количество отправляемых сообщений в час, поэтому один не получает 50 см за короткое время. Я вижу подобные подходы в больших масштабах - nagios - это просто скелет, и люди пишут вокруг него и фактически используют все меньше и меньше его функций.
PQD

1
Что касается иерархии, то, что я сейчас имею, это полностью «модульная» установка Nagios, где ваш каталог etc / содержит конфигурацию «core», которая является общей (и идентичной) для всех хостов, а затем etc / modules / $ NAME (т.е. : Почта, Интернет, Сеть, DNS), которая на 100% переносима между серверами. Включить с помощью cfg_dir =). Вы помещаете любые специфичные для модуля команды, плагины и все, что находится в этом каталоге. Заставить> 1 сервер выполнить эти проверки довольно легко, поскольку вы просто копируете модуль в столько блоков Nagios, сколько требуется, однако, опять же, логика оповещения вызывает проблемы :-)
nixgeek

1
@ Astinus # 2. в моем случае репликация конфигурации master-> slave происходит каждые 6 часов. если мастер просто умирает [отключение питания и т. д.] - ведомый предупредит всех о смерти мастера [перекрестная проверка между серверами]. Можно представить другой сценарий - когда мастер умирает из-за неправильной конфигурации. если это произойдет за 5 минут до синхронизации конфигурации с ведомым устройством - будет уведомление. если это происходит непосредственно перед синхронизацией конфигурации - к сожалению, в итоге мы не имеем системы мониторинга. «кто будет наблюдать за сторожем»? ну, может быть, еще один очень простой nagios.
PQD

1
@pQd - интересно, я согласен, что реализация логики в пользовательских скриптах уведомлений - это, вероятно, путь. Однако становится довольно сложно избежать дублирования уведомлений от 2+ хостов, когда у вас есть, скажем, 50 отслеживающих хостов, и я еще не видел, чтобы кто-нибудь (публично) использовал свою общую логику в правильной системе передачи «сообщений», такой как Rabbit или Amazon. SQS.
nixgeek

1
@ astinus # 3 в моем случае это было решение «Уровень 8» [модели iso osi]: первичные нагио отправляли sms'ы людям по вызову + по почте 24/5 «группе разрешения», в то время как 2-е нагио занимались только рассылкой » группа резольвера. это было до этой группы, чтобы отфильтровать дубликаты до эскалации;
PQD

1

То, что вы просите, звучит очень похоже на то, что Shinken сделал для Nagios.

Shinken - это перезапись Nagios.

  • Современный язык (Python)
  • Современная структура распределенного программирования (Pyro)
  • Мониторинг Realms (мультитенантность), HA, запчасти
  • Livestatus API
  • Совместимость с плагином Nagios
  • Нативное исполнение NRPE
  • Деловая критичность объектов
  • Бизнес-правила могут применяться к состоянию объектов (управление доступностью кластера или пула)
  • Для построения графиков можно использовать графит или RRDtool на основе PNP4nagios
  • Стабильно и развертывается в больших средах
  • В крупных развертываниях можно рассмотреть возможность сопряжения его со Splunk для создания отчетов или просмотра Graphite, где RRDtool не подходит.

Это должно быть пищей для размышлений.

ура

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.