Исходное сообщение
"NetXMS - новая, быстро развивающаяся система мониторинга" Отправлено Alex Kirhenshtein, 14-Июн-07 01:11
> По архитектуре и методикам обработки ближе к zabbix. Не совсем. Заббикс завязан на базу, и в этом их очень большая проблема. Забрали значение с агента, insert в базу. Пришел юзер на веб - select соорудили. Из этого вытекают проблемы вида "удаляем ноду из базы вместе с историей, скажем, при этом ничего не собирается - база полочила таблицы, insert-ы не проходят, пока всё не удалится" (это пример из их рассылки, в качестве решения предложено сменить базу на более шуструю). Из этой же прямой работы с базой вытекают огромные проблемы с stand-alone клиентом (и конкурентными пользователями системы). У нас, в свою очередь, всё хранится в памяти, и синхронизируется с базой отдельными потоками. При этом могут одновременно работать несколько администраторов, каждый со своими группами серверов, скажем. Плюс, такая архитектура позволяет делать удобные штуки типа подписки на события - т.е. скажем малентькому тулу из трея, который показывает тревоги, не надо постоянно pool-ить сервер, ему достаточно подписаться на получение новых тревог. Замечательно работает на GPRS-е, скажем. Да, про перфоманс и требования к памяти: один из наших клиентов, у которых сейчас больше 300-т нод, сервер гоняет на старом p3/700 с 512 памяти под FreeBSD, база бежит на той же машине. В рассылке у нас есть человек из норвежского ISP, который пробовал мониторить рутера с количеством интерфейсов больше трёх тысяч. Не знаю, впрочем, про железо, на котором это всё бегало - но бегало, и хорошо.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> По архитектуре и методикам обработки ближе к zabbix. > Не совсем. Заббикс завязан на базу, и в этом их очень большая > проблема. Забрали значение с агента, insert в базу. Пришел юзер на > веб - select соорудили. Из этого вытекают проблемы вида "удаляем ноду > из базы вместе с историей, скажем, при этом ничего не собирается > - база полочила таблицы, insert-ы не проходят, пока всё не удалится" > (это пример из их рассылки, в качестве решения предложено сменить базу > на более шуструю). Из этой же прямой работы с базой вытекают > огромные проблемы с stand-alone клиентом (и конкурентными пользователями системы). > У нас, в свою очередь, всё хранится в памяти, и синхронизируется с > базой отдельными потоками. При этом могут одновременно работать несколько администраторов, > каждый со своими группами серверов, скажем. Плюс, такая архитектура позволяет делать > удобные штуки типа подписки на события - т.е. скажем малентькому тулу > из трея, который показывает тревоги, не надо постоянно pool-ить сервер, ему > достаточно подписаться на получение новых тревог. > Замечательно работает на GPRS-е, скажем. > Да, про перфоманс и требования к памяти: один из наших клиентов, у > которых сейчас больше 300-т нод, сервер гоняет на старом p3/700 с > 512 памяти под FreeBSD, база бежит на той же машине. В > рассылке у нас есть человек из норвежского ISP, который пробовал мониторить > рутера с количеством интерфейсов больше трёх тысяч. Не знаю, впрочем, про > железо, на котором это всё бегало - но бегало, и хорошо.
	Введите код, изображенный на картинке: