Система мониторинга, масштабируемая до 1000 хостов и 100000 переменных

Вам нужно будет ответить еще на несколько вопросов, прежде чем мы действительно сможем дать вам предложение. Для начала, хотите ли вы хранить необработанные данные в течение 5 лет? Или достаточно ли свернутых данных? Это имеет большее значение, чем вы думаете, и только эта функция может определять ваши варианты.

Когда вы говорите о 5-летнем промежутке времени, вы почти всегда говорите о трендовой информации, которая будет накапливаться, и вы со временем потеряете точность. Если вы не собираете данные, вы имеете дело с огромным объемом данных, и очень немногие системы (как программные, так и аппаратные) смогут с ними справиться.

К счастью, вот почему RRDtool и были изобретены циклические базы данных (RRD). Если вы его не узнаете, ничего страшного. Вы можете не знать названия, но если вы посмотрите на инструменты с открытым исходным кодом, вы увидите практически все, что построено на его основе. Практически любая программа с открытым исходным кодом, которая отслеживает тенденции данных во времени и дает вам красивые графики, вероятно, использует RRDtool под капотом. RRDtool создает базы данных фиксированного размера, которые автоматически объединяют данные и сохраняют фиксированную точность до указанных пределов. Например, вы можете хранить данные за 30 дней с точностью до 5 минут, данные за 90 дней с точностью до 30 минут, данные за 180 дней с точностью до часа, данные за 365 дней с точностью до 1 дня, данные за 3 года. данные с точностью до 1 недели и данные за 10 лет с точностью до месяца. Все это настраивается, и каждый раз, когда вы добавляете новую точку данных, она вычисляет сводные данные.

Теперь, когда вы точно определите, каковы ваши требования к хранению данных, вам нужно выяснить, как вы планируете контролировать системы. При большом количестве устройств, особенно при большом количестве сетевых устройств, протокол SNMP является стандартом. Кроме того, существует множество устройств, которые не могут контролироваться ничем, кроме SNMP, поэтому важен хотя бы некоторый уровень поддержки SNMP (например, ИБП, генераторы, принтеры и т. Д.). Если у вас много серверов, вы можете выбрать систему на основе агентов, в которой вы устанавливаете агент мониторинга на каждое отслеживаемое устройство. Это часто дает вам более подробную информацию, но значительно увеличивает затраты на управление.

Затем вам нужно знать, какой ваш прогнозируемый рост выходит за рамки того, «что обрабатывает X, а что - 10 раз X». Даже для перечисленных 1k хостов 1k сильно отличается от 10k хостов. Многие системы будут обрабатывать 1 КБ, но когда вы приблизитесь к 10 КБ, вам часто понадобится распределенная система для распределения нагрузки. Кроме того, вы указываете 100 переменных для каждой системы, которую хотите отслеживать. . . Вы уверены, что? Не так много систем мониторинга, которые поддерживают мониторинг такого количества переменных. Это много информации, получаемой с каждого устройства.

Наконец, когда вы начинаете приближаться к большим масштабам, вам нужно учитывать гораздо больше, чем систему мониторинга. Для извлечения 100 бит переменных данных из 1k (или 10k) устройств с 5-минутным разрешением потребуется довольно серьезная пропускная способность. Будьте готовы к этому, иначе вы можете обнаружить, что ваша система мониторинга негативно влияет на вашу сеть. Это особенно важно, если ваши системы распределены по нескольким сайтам и вы пересекаете ссылки WAN.

Есть несколько систем с открытым исходным кодом, претендующих на конкурентоспособность в этом большом масштабе сетевого мониторинга, но их немного. Nagios существует уже давно и, как известно, контролирует системы 1k +. Зенос предлагает как основной продукт с открытым исходным кодом, так и продукт с коммерческой поддержкой, и пытается бросить вызов некоторым «крупным игрокам». Zabbix является полностью открытым исходным кодом при поддержке компании.

Однако, когда дело доходит до крупных компаний с тысячами устройств / систем, нуждающихся в мониторинге, крупнейшими игроками являются Spectrum / eHealth / Unicenter от CA, пакет Tivoli от IBM, OpenView от HP. Каждый из них может работать с огромными весами, но также имеет огромный Ценники.

Примечание. Работа My Day - это внедрение и обслуживание инструментов сетевого мониторинга, где мы отслеживаем более 5 тысяч сетевых устройств и 8 тысяч серверов. Поиск работающих инструментов хорошо в этих масштабах жесткий.

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

Помимо хорошего масштабирования, он гибкий и простой в настройке.

Я бы сказал либо Нагиос, либо Зенос:

Nagios http://www.nagios.org

Зенос http://www.zenoss.com

Любой из них должен быть в состоянии удовлетворить ваши требования при правильной настройке.

На работе мы используем Opsview для этого. Он построен на Nagios и обрабатывает данные записи и тому подобное. Запросы на мониторинг обрабатываются кластером контролирующих узлов и передаются мастеру. Это может быть удобно, если у вас несколько центров обработки данных, но мы в основном используем его для резервирования и балансировки нагрузки. Я думал, что он использует RRDtool, но, похоже, он использует MySQL.

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

Затем объем данных, которые вы храните, составляет порядка 80 МБ на хост в год, при условии, что вы фактически умещаете 100 выборок в 800 байт. (RRD требует около 8 байт на выборку). Вся система будет потреблять 80 ГБ в год, и ее будет сложно запросить. В 10 раз больше, и вам понадобится помощь Google. Если вы сделаете что-нибудь глупое, например, запишите результаты ps, горе вам.

Серьезно, Том, просто расскажите нам, что на этот раз изобрела Google, или попросите свою чертову компанию написать то, что вам нужно, на MapReduce и BigTable. В масштабе Google лучшим планом может быть серьезная реорганизация таких форматов, как RRD, чтобы они лучше соответствовали избыточности ваших данных.

ознакомьтесь с этой веткой slashdot, чтобы получить массу предложений;)

http://ask.slashdot.org/story/09/07/08/210241/What-Would-You-Want-In-a-Large-Scale-Monitoring-System

Мы используем Zabbix для мониторинга 150 хостов и 10 серверов.

Он должен удовлетворить ваши потребности.

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