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

Приветствую,

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

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

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

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

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

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

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

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

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

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

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

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

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