В настоящее время я оцениваю программное обеспечение для мониторинга (по моим стандартам) более крупной сети, которая, как ожидается, вырастет примерно до 3000 устройств. Мне трудно найти данные о требованиях к оборудованию для масштабирования. (Изменить: устройства - это спутниковые приемники, контролируемые SNMP, поэтому требуется монитор без агентов. Наша основная задача - выявить неисправные устройства, и нам не нужен большой анализ.)
Каждое 3000 устройств будет иметь около 40 точек данных, регистрируемых в цикле от 5 до 10 минут. При 10-минутном интервале опроса это 12 000 точек в минуту. Это обеспечивает два вида нагрузки: нагрузку на ЦП для приложения опроса и, что наиболее важно, нагрузку на запись на диск для хранения этих точек данных.
Я посмотрел на Solarwinds Orion, Zenoss, Zabbix и OpenNMS. У нас есть опыт использования Zenoss и Orion в небольших сетях из нескольких сотен устройств. Мои первые впечатления:
Есть ли у кого-нибудь опыт или данные о производительности для мониторинга сети такого масштаба?
OpenNMS может сделать эту работу.
Для этого типа среды ключом будут потоки ЦП и что-то, что может обрабатывать запись на диск с низкой задержкой. Я бы использовал автономный сервер (вместо виртуальной машины), предоставил бы 12 или более ядер и спланировал бы использование хранилища с прямым подключением, которое имеет 6 или более шпинделей или может использовать SSD для каталогов OpenNMS RRD. OpenNMS также можно настроить на фронтах сбора данных и регистрации, чтобы сделать его более эффективным. Обратиться к их команде профессиональных услуг, чтобы помочь с установкой, было бы хорошим вариантом.
Насколько мне известно, Zabbix имеет установки с 10k + устройствами. Возможно, вам нужно распределить нагрузку, т.е. разместить сервер базы данных (если он нужен вашему решению) на другой машине. Вы также можете посмотреть Zabbix Proxy.
У меня есть опыт мониторинга сетей такого размера. Кроме того, я всегда оцениваю новые возможности, когда речь идет о решениях для мониторинга.
Тем не менее, я исхожу с большей точки зрения Microsoft, чем вы, и я даже не уверен, рассмотрю ли я некоторые из упомянутых вами решений корпоративного уровня, но я все равно смогу помочь.
Почти каждая система мониторинга будет состоять из нескольких общих компонентов - базы данных и серверов управления. (NetIQ, Nimsoft, Quest, VMware, SCOM, и это лишь некоторые из них.)
Количество оборудования, которое вам понадобится, во многом зависит от того, как вы планируете осуществлять мониторинг, в частности, от того, сколько точек данных вы хотите захватить. Для самых простых вещей, таких как загрузка ЦП, память, дисковое пространство и т. Д., Ваши требования будут меньше. Если вы хотите отслеживать огромное количество метрик приложений, таких как количество веб-запросов в секунду, которые получают ваши хосты, сканирование файлов журнала на предмет ключевых слов и т. Д., Тогда объем данных, собранных вашей системой мониторинга, будет намного больше, и все строго требования к оборудованию будут расти.
Также следует учитывать такие факторы, как: хотите ли вы загружать агентов на каждую машину (обычно позволяет получить более подробную информацию) или вы хотите попробовать полностью отказаться от агентов? Вы контролируете все физические машины, все виртуальные машины или их комбинацию? Как насчет сетевого оборудования, вы его тоже отслеживаете? В больших гетерогенных сетях, подобных этой, вы обычно получаете несколько решений, работающих вместе, чтобы покрыть все ваши базы. Если у вас есть целая лодка виртуальных машин для мониторинга, некоторые решения, такие как VMware VC Ops и Quest vFoglight, получают информацию от самого vCenter (или нескольких vCenters), что означает, что многие метрики более точны, чем если бы они были измерены на самой виртуальной машине. , а также это означает, что вам, возможно, не придется загружать агент на виртуальную машину. Вы также обычно можете втиснуть больше машин в решение для мониторинга только виртуальных машин. Сегодня у VMware VC Ops есть клиенты, которые используют 10 тысяч виртуальных машин на одном экземпляре VC Ops.
Тем не менее, по моему личному мнению, VC Ops - это больше похоже на большой модный аналитический движок, чем на реальное решение для мониторинга. Приятно видеть, как он сообщает вам, что «в зависимости от вашего текущего роста, хост ESXi [x] в Datacenter [y] достигнет мощности через 30 дней».
Хорошо, в общем, существует множество разных способов разработки базы данных, но помните, что вам нужна высокая доступность. Вы не можете работать в такой огромной сети и стать владельцем решения для мониторинга, которое полностью отключится, если один из узлов вашей базы данных выйдет из строя. Так что не покупайте 1 сервер HP Proliant. Но два. Или три. Сгруппируйте их. План для HA. Итак, цена - 30 тысяч долларов?
Во-вторых, многие из этих решений будут выполнять роль «сервера управления» в своей инфраструктуре. По моему опыту, их обычно можно просто виртуализировать. Они действуют как посредники между агентами и центральным репозиторием, балансируя нагрузку и гарантируя, что все данные, поступающие от тысяч агентов, помещаются в репозиторий упорядоченным образом. Вы обнаружите, что в решениях такого типа у вас должно быть несколько серверов управления для HA, но вам не нужно слишком много, поскольку каждый дополнительный сервер управления вызовет конкуренцию и блокировки, поскольку все они просто вставляют данные в репозиторий. .
Так что запланируйте для них один или два хоста виртуализации. Может, еще 15 тысяч долларов? Это просто парк мячей. Я не знаю, собирается ли ваша компания строить это на новом оборудовании Cisco UCS или на Dell PowerEdges, которые вы покупаете у Craigslist.
Большинство решений корпоративного уровня достаточно настраиваемы, чтобы можно было использовать SQL Server, MySQL или даже Postgres. Однако очень немногие из них абсолютно хороши во всем, и я обычно вижу, что компания выполняет два или более решения для мониторинга параллельно.
редактировать: Также не забывайте планировать географическое распространение. У меня есть серверы, которые физически находятся в Амстердаме, и за ними наблюдают из Майами. Это возможно, но я не очень горжусь признанием этого.
edit # 2: Также важно отметить, что, хотя некоторые компании очень брезгливы в отношении траты денег на программное обеспечение - это просто зависит от культуры компании - хорошая компания осознает ценность поддержки Enterprise. Просто нужно иметь в виду.
Исходя из университетской среды, где мы выполняли мониторинг доступности (Ok / Warning / Critical с предупреждениями) и мониторинг производительности (построение графиков, RRD) МНОГИХ сетевых устройств (в основном Cisco, но проверяли множество показателей) ...
Я думаю, что это переоценено. Прежде всего, определите минимальный набор показателей, которые вам нужны, какое разрешение и сколько времени вам нужно для их хранения. Даже если вам действительно нужно опрашивать каждое из 3000 устройств каждые 5-10 минут для 40 метрик, нужно ли вам сохранять на них графические данные RRD, или вы можете просто использовать что-то вроде Nagios, чтобы предупреждать, если метрика выходит за пределы предопределенный порог?
Кроме того, насколько это должно быть надежно?
Вот как я бы это сделал, имея в виду, что моя точка зрения по умолчанию - минимальная стоимость, открытый исходный код и предположение, что кто бы это ни реализовал, может сделать код: