Система мониторинга сети и приложений, разработанная для работы в крупных корпоративных сетях.
Особенности системы:
- Трёхуровневая архитектура
- Сбор информации через SNMP и собственных агентов (на большинстве UNIX систем, включая коммерческие, а также Windows и IPSO)
- Централизованное обновление агентов
- Гибкая система разграничения доступа
- Гибкая система обработки событий
- Возможность сбора информации (включая SNMP) из сетей находящихся за NAT-ом через проксирующего агента
- Шифрованные коммуникации
- Поддержка кластеров (миграция ресурсов между нодами, etc.)
- Ядро системы и агенты переносимы между POSIX-совместимыми системами.
- Модульная архитектура дает возможность легкого расширения функциональности.
URL: http://www.netxms.org/
Новость: https://www.opennet.ru/opennews/art.shtml?num=11076
управляется виндовской программой
есть веб интерфейс - но не собирается
А какие ошибки при сборке веб-интерфейса?Кстати, консоль работает также и под Wine (не самый хороший вариант конечно...)
>А какие ошибки при сборке веб-интерфейса?
>
>Кстати, консоль работает также и под Wine (не самый хороший вариант конечно...)
>да кстати, как только узнал что нет нативной консоли для линукса - сразу подпортило впечатление
кто нибудь может сравнить сабж с zabbix, nagios?
>кто нибудь может сравнить сабж с zabbix, nagios?
По архитектуре и методикам обработки ближе к zabbix. Из минусов без виндовой консоли не конфигурабелен.
> По архитектуре и методикам обработки ближе к zabbix.Не совсем. Заббикс завязан на базу, и в этом их очень большая проблема. Забрали значение с агента, insert в базу. Пришел юзер на веб - select соорудили. Из этого вытекают проблемы вида "удаляем ноду из базы вместе с историей, скажем, при этом ничего не собирается - база полочила таблицы, insert-ы не проходят, пока всё не удалится" (это пример из их рассылки, в качестве решения предложено сменить базу на более шуструю). Из этой же прямой работы с базой вытекают огромные проблемы с stand-alone клиентом (и конкурентными пользователями системы).
У нас, в свою очередь, всё хранится в памяти, и синхронизируется с базой отдельными потоками. При этом могут одновременно работать несколько администраторов, каждый со своими группами серверов, скажем. Плюс, такая архитектура позволяет делать удобные штуки типа подписки на события - т.е. скажем малентькому тулу из трея, который показывает тревоги, не надо постоянно pool-ить сервер, ему достаточно подписаться на получение новых тревог.
Замечательно работает на GPRS-е, скажем.Да, про перфоманс и требования к памяти: один из наших клиентов, у которых сейчас больше 300-т нод, сервер гоняет на старом p3/700 с 512 памяти под FreeBSD, база бежит на той же машине. В рассылке у нас есть человек из норвежского ISP, который пробовал мониторить рутера с количеством интерфейсов больше трёх тысяч. Не знаю, впрочем, про железо, на котором это всё бегало - но бегало, и хорошо.
>Не совсем.
Совсем :) Я говорю о методиках обработки и генерации событий. А не про то как хранятся данные.>Заббикс завязан на базу, и в этом их очень большая проблема.
Проблема не в том что заббикс завязан на базу, а в том как он работает с данными.>Забрали значение с агента, insert в базу.
Проблема в том что обработка данных не атомарная. Атомарной она делается при помощи транзакций. На данный момент модель там потоковая т.е. оно манипулирует значениями, а не узлами.>Пришел юзер на веб - select соорудили. Из этого вытекают проблемы вида "удаляем ноду
>из базы вместе с историей, скажем, при этом ничего не собирается
>- база полочила таблицы, insert-ы не проходят, пока всё не удалится"
А это не проблема Zabbix это детская болезнь таблиц MyISAM в MySQL. При использовании InnoDB или другой СУБД этого не происходит.>Из этой же прямой работы с базой вытекают огромные проблемы с stand-alone клиентом (и >конкурентными пользователями системы).
Из-за не правильной работы с базой вытекают высокие требования к СУБД.>У нас, в свою очередь, всё хранится в памяти, и синхронизируется с
>базой отдельными потоками.
Эээ и сколько это все занимает в памяти? Может вы все же текущие состояния храните, а не все?>При этом могут одновременно работать несколько администраторов, каждый
>со своими группами серверов, скажем.
Zabbix это тоже позволяет. Так как вебинтерфейс работает не зависимо от самого сервера. А у вас же web сервер представляет часть сервера мониторинга. Зачем это надо я лично не понимаю.>Плюс, такая архитектура позволяет делать удобные
>штуки типа подписки на события - т.е. скажем малентькому тулу из
>трея, который показывает тревоги, не надо постоянно pool-ить сервер, ему достаточно
>подписаться на получение новых тревог.
Zabbix это так же замечательно делает. У меня к примеру приходят извещения по почте и в jabber. Дополнительно так же происходит сброс SMS на телефон на отдельные события.
>Да, про перфоманс и требования к памяти: один из наших клиентов, у
>которых сейчас больше 300-т нод, сервер гоняет на старом p3/700 с
>512 памяти под FreeBSD, база бежит на той же машине.
А сколько у нод параметров ? Если два-три на каждый, то ничего удивительного. Лучше приведите количество обрабатываемых значений.>В рассылке у нас есть человек из норвежского ISP, который пробовал мониторить
>рутера с количеством интерфейсов больше трёх тысяч. Не знаю, впрочем, про
>железо, на котором это всё бегало - но бегало, и хорошо.
На zabbix тоже будет бегать. Без особых проблем.Пока же из притензий к этому мониторингу:
1. Нет нормального вебинтерфейса.
2. Управление только из вашей интерфейсной программы.
3. Не нашел описания протокола взаимодействия интерфейсной программы с вашим ПО.Так как у меня нет Windows на рабочем месте, то меня это немного напрягает.
>>Не совсем.
>Совсем :) Я говорю о методиках обработки и генерации событий. А не
>про то как хранятся данные.Не совсем :) У нас центром является обработка событий, а в Zabbix'e события - побочный продукт, все завязано на триггеры - выполнение команд и т.д. У нас это называется thresholds и является только одним из поставщиков событий. Как следствие, работа с такими вещами как SNMP traps в Zabbix'e очень неудобна. Попробуйте например сделать такую вещь - "послать SMS админу если любой хост в субнете 10.0.0.0/16 прислал SNMP trap 'interface down', причем SMS должен содержать номер иноерфейса". У нас это делается за 30 сек. одним правилом в event processing policy.
>>У нас, в свою очередь, всё хранится в памяти, и синхронизируется с
>>базой отдельными потоками.
>Эээ и сколько это все занимает в памяти? Может вы все же
>текущие состояния храните, а не все?Конечно текущие :) Плюс необходимая история для проверки условий - если в условии стоит "среднее значение за 10 опросов", то в памяти будет 10 последних значений.
>
>>При этом могут одновременно работать несколько администраторов, каждый
>>со своими группами серверов, скажем.
>Zabbix это тоже позволяет. Так как вебинтерфейс работает не зависимо от самого
>сервера. А у вас же web сервер представляет часть сервера мониторинга.
>Зачем это надо я лично не понимаю.web сервер - это такой-же клиент, как и консоль. Т.е. их может быть много, разных, на разных машинах.
>Не совсем :) У нас центром является обработка событий, а в Zabbix'e
>события - побочный продукт, все завязано на триггеры - выполнение команд
>и т.д.
Так события на основе чего генерятся? Может на основе определенного значения у узла? Если нет и события могут быть порождены только какими либо внешними событиями типа snmp trap, то как-то мне это не очень нравится. Zabbix хорошо именно тем что сначала собираются данные, а уже на их основе что-то генерируется.>Как следствие, работа с такими вещами как SNMP
>traps в Zabbix'e очень неудобна. Попробуйте например сделать такую вещь -
>"послать SMS админу если любой хост в субнете 10.0.0.0/16 прислал SNMP
>trap 'interface down', причем SMS должен содержать номер иноерфейса". У нас
>это делается за 30 сек. одним правилом в event processing policy.
Там так же. Событие может генерироваться от группы триггеров. У меня сейчас 202 триггера. Их обрабатывает 17 генераторов событий. Так что не надо ля-ля.>Конечно текущие :) Плюс необходимая история для проверки условий - если в
>условии стоит "среднее значение за 10 опросов", то в памяти будет
>10 последних значений.
Так у вас таки есть генерация событий на базе полученных данных? И являются ли они основными?>web сервер - это такой-же клиент, как и консоль. Т.е. их может
>быть много, разных, на разных машинах.
Конечно. Только вот где у вас унифицированный интерфейс взаимодействия клиента с сервером?
>Так события на основе чего генерятся? Может на основе определенного значения у
>узла? Если нет и события могут быть порождены только какими либо
>внешними событиями типа snmp trap, то как-то мне это не очень
>нравится. Zabbix хорошо именно тем что сначала собираются данные, а уже
>на их основе что-то генерируется.Источники событий могут быть следующими:
1. Превышение пороговых значений собираемыми параметрами (типа CPU usage > 50%) - аналог Zabbix триггеров.
2. SNMP traps
3. События посланные агентом
4. События посланные внешним приложением (через клиентскую библиотеку или команду nxevent)
5. Изменение статуса объекта - ушел в down, недоступен агент, изменилась конфигурация, etc.
6. Network discovery - нашли новый хост
7. Внутренние события - напр., потеряли коннект с базой
8. Alarm timeouts - если операторы долго не реагируют на новый аларм, можно послать event>
>>Как следствие, работа с такими вещами как SNMP
>>traps в Zabbix'e очень неудобна. Попробуйте например сделать такую вещь -
>>"послать SMS админу если любой хост в субнете 10.0.0.0/16 прислал SNMP
>>trap 'interface down', причем SMS должен содержать номер иноерфейса". У нас
>>это делается за 30 сек. одним правилом в event processing policy.
>Там так же. Событие может генерироваться от группы триггеров. У меня сейчас
>202 триггера. Их обрабатывает 17 генераторов событий. Так что не надо
>ля-ля.А можно step-by-step как это быстро в Zabbix'e сконфигурить, я возможно просто давно его не смотрел :)
>
>>web сервер - это такой-же клиент, как и консоль. Т.е. их может
>>быть много, разных, на разных машинах.
>Конечно. Только вот где у вас унифицированный интерфейс взаимодействия клиента с сервером?Есть портабельная библиотека libnxcl, которая предоставляет API для работы с сервером по сети и есть на Windows, Linux, Solaris, HP-UX, ... даже для Pocket Windows.
>Источники событий могут быть следующими:
>1. Превышение пороговых значений собираемыми параметрами (типа CPU usage > 50%) - аналог Zabbix триггеров.В zabbix триггеры умеют существенно больше. Так как они из себя представляют вычисляемое выражение. Как вам такое: триггер включается только если в течении 5 минут исходящий поток на трех интерфейсах превышает 5 мегабит в субботу с 17 часов до 19? У вас такое можно? Zabbix левой ногой.
>2. SNMP traps
>3. События посланные агентом
>4. События посланные внешним приложением (через клиентскую библиотеку или команду nxevent)
>5. Изменение статуса объекта - ушел в down, недоступен агент, изменилась конфигурация,
>etc.
Есть в zabbix. Последнее посложнее но возможно.>6. Network discovery - нашли новый хост
Нету но обещают.>7. Внутренние события - напр., потеряли коннект с базой
Есть но с ограничениями.>8. Alarm timeouts - если операторы долго не реагируют на новый аларм,
>можно послать event
Если повторная отправка несколько раз. Есть возможность поставить уведомление о полученной тревоге и оставить комментарий.>А можно step-by-step как это быстро в Zabbix'e сконфигурить, я возможно просто
>давно его не смотрел :)
1. Создаем шаблон с необходимыми триггерами.
2. Привязываем однотипные узлы к шаблону.
3. Создаем actions с условием что описание trigger похоже на этот триггер. Ключевой момент это уникальные описания триггеров.>Есть портабельная библиотека libnxcl, которая предоставляет API для работы с сервером по
>сети и есть на Windows, Linux, Solaris, HP-UX, ... даже для
>Pocket Windows.
Начем? На C ? А что делать с Java и т.п. языками? Нужна не библиотека а описание протокола.
>>Источники событий могут быть следующими:
>>1. Превышение пороговых значений собираемыми параметрами (типа CPU usage > 50%) - аналог Zabbix триггеров.
>
>В zabbix триггеры умеют существенно больше. Так как они из себя представляют
>вычисляемое выражение. Как вам такое: триггер включается только если в течении
>5 минут исходящий поток на трех интерфейсах превышает 5 мегабит в
>субботу с 17 часов до 19? У вас такое можно? Zabbix
>левой ногой.Можно. Называется conditions. Можно составлять условия любой сложности (фактически писать скрипты), в качестве исходных данных можно использовать собираемые данные с любых хостов.
Я с автором Zabbix'a 10 лет в одном классе учился, а потом в универе, и в свое время немного в разработке Zabbix'a участвовал (написал Windows агент, и во всяких обсуждениях учасвовал) :) Поэтому некоторые идеи пересекаются...
>>А можно step-by-step как это быстро в Zabbix'e сконфигурить, я возможно просто
>>давно его не смотрел :)
>1. Создаем шаблон с необходимыми триггерами.
>2. Привязываем однотипные узлы к шаблону.
>3. Создаем actions с условием что описание trigger похоже на этот триггер.
>Ключевой момент это уникальные описания триггеров.А как выглядит триггер для SNMP trap'a? Понятие триггера подразумевает переключение true/false, а как это к SNMP trap'у применить? Если это например trap от backup системы, в котором в одном из параметров прописано название проблемной сессии, и я хочу это название сессии показать оператору? Или трапы interface down/interface up, где парность есть, но трапы разные, и надо еще на индех интерфейса внутри смотреть - чтобы узнать - это повторное сообщение об одном и том-же, или уже другой интерфейс упал.
>>Есть портабельная библиотека libnxcl, которая предоставляет API для работы с сервером по
>>сети и есть на Windows, Linux, Solaris, HP-UX, ... даже для
>>Pocket Windows.
>Начем? На C ? А что делать с Java и т.п. языками?
>Нужна не библиотека а описание протокола.Библиотека на С, в разработке Java версия и wrapper для Python. Описание протокола можно сделать, никто просто пока не спрашивал...
>Можно. Называется conditions. Можно составлять условия любой сложности (фактически писать скрипты), в
>качестве исходных данных можно использовать собираемые данные с любых хостов.
Скрипты не требуются. Требуются именно выражения. Надеюсь у вас выражения хранятся в виде обратной польской записи?>Я с автором Zabbix'a 10 лет в одном классе учился, а потом
>в универе, и в свое время немного в разработке Zabbix'a участвовал
>(написал Windows агент, и во всяких обсуждениях учасвовал) :) Поэтому некоторые
>идеи пересекаются...
Вот а потом вы мне рассказываете что у вас нет сходных идей :)
>
>А как выглядит триггер для SNMP trap'a? Понятие триггера подразумевает переключение true/false,
>а как это к SNMP trap'у применить?
интерпретируется как значение и дальше обрабатывается триггером.>Если это например trap
>от backup системы, в котором в одном из параметров прописано название
>проблемной сессии, и я хочу это название сессии показать оператору? Или
>трапы interface down/interface up, где парность есть, но трапы разные, и
>надо еще на индех интерфейса внутри смотреть - чтобы узнать -
>это повторное сообщение об одном и том-же, или уже другой интерфейс
>упал.
Каждый трап отслеживается как отдельный item со значением. Просто надо правильно интерпертировать snmp trap в значение и потом это значение обработать триггером. Система сама по себе гибкая, но кое какой гемморой при этом будет присутствовать это факт.
>Библиотека на С, в разработке Java версия и wrapper для Python. Описание
>протокола можно сделать, никто просто пока не спрашивал...
Желательно чтобы было еще описание протокола. В этом случае будет проще сделать свою реализацию консоли на чем угодно.
А почему интересно графики не в rrdtool рисуются, а своим кодом?
>А почему интересно графики не в rrdtool рисуются, а своим кодом?
Потому что использование рисования графиком rrdtool показатель пионерии. Так как rrdtool не умеет нативно рисовать графики из СУБД. И работать с данными в формате баз rrdtool не особо удобно, особенно когда таких данных много.
Я сильно сомневаюсь, что на больших объемах данных SQL будет быстрее чем RRD.
База фиксированного размера (в rrd) должна работать быстрее чем универсальный сторадж SQL который ничего не знает о том, что данные нужно хранить фиксированного объема (не собираетесь же вы вечно хранить данные с 5-и минутным интервалом). SQL ничего не знает и про то что часть запросов никогда не понадобится (и поэтому его схема хранения не будет оптимальной для данной задачи).SQL это универсально, но в тех случаях когда есть узко специализированные базы (типа RRD) работают они как правило лучше.
>Я сильно сомневаюсь, что на больших объемах данных SQL будет быстрее чем
>RRD.
Медленнее.>База фиксированного размера (в rrd) должна работать быстрее чем универсальный сторадж SQL
>который ничего не знает о том, что данные нужно хранить фиксированного
>объема (не собираетесь же вы вечно хранить данные с 5-и минутным
>интервалом). SQL ничего не знает и про то что часть запросов
>никогда не понадобится (и поэтому его схема хранения не будет оптимальной
>для данной задачи).
Вот как раз будет. В отличии от rrd я могу посмотреть любой удобный интервал. Главное бы данные были. В rrd этого нет.>SQL это универсально, но в тех случаях когда есть узко специализированные базы
>(типа RRD) работают они как правило лучше.
Если мне надо посмотреть график за 5 минут за 12 часов за сутки за месяц то да. Но если надо несколько гибче да еще надо что-то кроме графиков, то rrd пролетает как фанера над парижем.
>>База фиксированного размера (в rrd) должна работать быстрее чем универсальный сторадж SQL
>>который ничего не знает о том, что данные нужно хранить фиксированного
>>объема (не собираетесь же вы вечно хранить данные с 5-и минутным
>>интервалом). SQL ничего не знает и про то что часть запросов
>>никогда не понадобится (и поэтому его схема хранения не будет оптимальной
>>для данной задачи).
>Вот как раз будет. В отличии от rrd я могу посмотреть любой
>удобный интервал. Главное бы данные были. В rrd этого нет.
RRD база - это константное количество значений на временной оси, расположенных с заданным интервалом.
Вопрос: КАКИМ нужно местом думать чтоб не суметь запросить множество значений
за необходимый интервал?>>SQL это универсально, но в тех случаях когда есть узко специализированные базы
>>(типа RRD) работают они как правило лучше.
>Если мне надо посмотреть график за 5 минут за 12 часов за
>сутки за месяц то да. Но если надо несколько гибче да
>еще надо что-то кроме графиков, то rrd пролетает как фанера над
>парижем.Тебе же написали: RRD - быстрее, но задача у нее УЖЕ по сравнию с SQL.
Что ты продолжаешь мерять свой узорчатый но медленный?
>Вопрос: КАКИМ нужно местом думать чтоб не суметь запросить множество значений
>за необходимый интервал?
А это тут причем? В случае с SQL я могу легко и не принужденно ничего не изменяя увеличивать и уменьшать этот интервал. У rrd это так легко не получится. Тоже самое могу сказать и про копирование или пересчет данных. Хранение данных в СУБД дает больше возможностей. rrd же позволяет выбирать линейные отрезки. В своей узкой области оно удобно, но не более.>Что ты продолжаешь мерять свой узорчатый но медленный?
Я ничего не меряю. Я высказываю свое мнение. И мое мнение таково что использовать в более-меннее серьезных системах мониторинга rrd не стоит.
>>Вопрос: КАКИМ нужно местом думать чтоб не суметь запросить множество значений
>>за необходимый интервал?
>А это тут причем? В случае с SQL я могу легко и
>не принужденно ничего не изменяя увеличивать и уменьшать этот интервал. У
>rrd это так легко не получится.
На самом деле в RRD храниться массив: UNIX время - значение.
Т.е. интеревала как такового нет. Он задаеться только скоростью добавления данных в базу.>Тоже самое могу сказать и
>про копирование или пересчет данных. Хранение данных в СУБД дает больше
>возможностей. rrd же позволяет выбирать линейные отрезки. В своей узкой области
>оно удобно, но не более.
Ты различаешь быстрее и удобнее? Так вот RRD БЫСТРЕЕ на определенных операциях.
Про гибкость SQL'я мы тут уже все наслышаны..
>>Что ты продолжаешь мерять свой узорчатый но медленный?
>Я ничего не меряю. Я высказываю свое мнение. И мое мнение таково
>что использовать в более-меннее серьезных системах мониторинга rrd не стоит.
Ты спутал SQL с RRD и высказываешься, что без SQL ничего серьезного не бывает.
ДА. Так оно и есть. Но кто сказал, что данные нужно собирать сразу в какой-нить мускуль?
Сбор - это рутина и она должна быть быстра. И только нужна более детальная обработка (да, да, все те сложные запросы с пачкой условий, сриптофф-на-перле и т.д.) - вот тут забирай данные из RRD базы в хранилище на SQL и рули куда нужно.
>На самом деле в RRD храниться массив: UNIX время - значение.
>Т.е. интеревала как такового нет. Он задаеться только скоростью добавления данных в
>базу.
Я знаю что такое RRD.>Ты различаешь быстрее и удобнее? Так вот RRD БЫСТРЕЕ на определенных операциях.
На линейных да.>ДА. Так оно и есть. Но кто сказал, что данные нужно собирать
>сразу в какой-нить мускуль?
А кто вам сказал что нельзя? Вполне можно. Но надо предварительно получать большой объем данных и помещать их туда при помощи транзакций одним большим куском.>Сбор - это рутина и она должна быть быстра. И только нужна
>более детальная обработка (да, да, все те сложные запросы с пачкой
>условий, сриптофф-на-перле и т.д.) - вот тут забирай данные из RRD
>базы в хранилище на SQL и рули куда нужно.
Объясните мне зачем сначала помещать данные в RRD, затем их оттуда доставать и помещать в СУБД? Может все же стоит накопить определенный объем данных и сбросить их СУБД одной транзакцией? :)
>Вот как раз будет. В отличии от rrd я могу посмотреть любой
>удобный интервал. Главное бы данные были. В rrd этого нет.
Есть. при заполнении базы можно её бэкапить. на джаваскрипте легко пишется обрамление к графику позволяющиее перейти на любой интервал, увеличить/уменьшить масштаб>>SQL это универсально, но в тех случаях когда есть узко специализированные базы
>>(типа RRD) работают они как правило лучше.
>Если мне надо посмотреть график за 5 минут за 12 часов за
>сутки за месяц то да.
*за любой промежуток присутвующий в базе. *быстро
>Но если надо несколько гибче да
>еще надо что-то кроме графиков, то rrd пролетает как фанера над
>парижем.
rrd предназначена для аккумулирования данных и постройки графиков любой конфигурации на основании этих данных
Ну а вообще, конечно, молоток это пионерия.. и лучше использовать микроскоп для забивания гвоздей..
>Есть. при заполнении базы можно её бэкапить. на джаваскрипте легко пишется обрамление
>к графику позволяющиее перейти на любой интервал, увеличить/уменьшить масштаб
Можно. Но не является нативным средством. К тому же мне интересно как вы будете показывать данные половина которых в одной базе, а вторая в другой.>*за любой промежуток присутвующий в базе. *быстро
Ключевой момент присутсвующий в базе. Потом есть еще одна проблема это то что у rrd нет механизмов разруливания записи несколькими клиентами.>rrd предназначена для аккумулирования данных и постройки графиков любой конфигурации на >основании этих данных
Я в курсе зачем оно необходимо. Но дело в том что тот же zabbix использует эти данные не только для посторения графиков, но еще и для генерации тревог, на базе вычисляемого значания по интервалу.
>Ну а вообще, конечно, молоток это пионерия.. и лучше использовать микроскоп для
>забивания гвоздей..
Инстументы надо по назначению использовать. rrd он неплох когда вам требуются только графики. Но как только вам потребуются не только графики наступает оппаньки.
Мне нужна система мониторинга.
Но ради этого ставить M$ или wine - мрачно....
Пока сам рисую и дописываю части.Если уж и писать - то писать надо под что-то одно, человеческое.
Много самому дописывать - долго и не удобно.
Да система мониторинга - хорошо.Но пока не появиться человеческого продукта полностью под Linux не буду даже пробовать ставить.
Мне зоопарка и так хватает.
А вот что вам интереснее - нативная консоль под Линукс, или полноценный веб-интерфейс?
>А вот что вам интереснее - нативная консоль под Линукс, или полноценный
>веб-интерфейс?Интереснее был бы вебинтерфейс. Если вам хочется сохранить модель работы аналогичную с windows-консолью, то посмотрите такие вещи как XML-RPC или SOAP.
www.nagios.org. нормальная система мониторинга промышленного уровня. Все сказанное про NetXMS делает с успехом, а то и больше.
Есть один минус у нагиоса - конфигурация.Тут всё заточено под то, чтоб всё можно было настраивать и управлять из одной точки - администраторской консоли. Просмотр логов, графики, правка конфигов агентов, их апгрейд, etc.
К примеру, апгрейд агентов выглядит так:
через консоль администратора заливаете на сервер новый пекедж (может быть в разных формах - исходники, готовые бинарники), после чего выбираете ноду(контейнер, всю сеть, etc) - и указываете, какой пекедж надо туда поставить. Всё делается из одной точки. Причем, агент для win32/x86 не будет наложен на Solaris, скажем.
С конфигами - аналогично, правый клик на ноде, "edit agent config" - и редактируем. Закончили - агент автоматом перезапустится.Никаких "ssh на хост1, потом ssh на хост2, потом делаем скриптик".
Или, скажем, агенты могут запрашивать конфиг у сервера - при старте. А сервер умеет отдавать нужный в зависимости от условий - будь то архитектура системы, версия агента, или hostname ноды.
Я не спорю, что это всё решается скриптами, но мы пытаемся сделать комплексное решение - чтоб не приходилось каждый раз писать мелкие "костыли"
очень и очень интересно...
три года пользуем нагиос, немалый уже есть опыт, но конфигурирование его это конечно песня еще та.. дак вот вопрос по теме - работает ли все таки WEB в этой штуке? в документации очень мало по этому поводу, а у нас дисперчера уже привыкли
На данный момент - только read only, к сожалению. Но мы работаем над этим.
налицо ошибочная стратегия пользовательского интерфейса.в век WEB-2.0 и начала конца венды делать ставку на маздаюную админку...
как минимум было неразумно....
ессьно, сейчас спохватились, но _что_ будет и _как_ сделано в этой спешке - это вопрос еще тот...
Одна из основных идей системы - модульность. Так, web интерфейс - это такой-же клиент, как и консоль, и использует он одну и ту-же клиентскую библиотеку (и располагатся кстати может на другой физической машине). Такой подход позволяет иметь неограниченное количество UI - можно сделать и консоль под X, и альтернативный web UI, и интеграцию с другими системами. С Windows консоли рачали только потому, что мне web интерфейсы не нравятся, а система во многом написана под себя и некоторых клиентов моей компании. Основная проблема - девелоперов только двое, и многие вещи не успеваем делать так быстро, как хотелось бы. Ну и суйчас я думаю, что было бы правильней консоль делать под wxWidgets - тогда бы ее легко можно было бы перенести на Linux. Мы этот вариант (переписать под wxWidgets) сейчас обдумываем - но в любом случае быстро это не будет.
много в чем наступила ясность с такими особенностями реализации
>Есть один минус у нагиоса - конфигурация.
Возьмите к примеру вот это http://www.groundworkopensource.com/ и никаких проблем с конфигурацией не будет>К примеру, апгрейд агентов выглядит так:
>через консоль администратора заливаете на сервер новый пекедж (может быть в разных
>формах - исходники, готовые бинарники), после чего выбираете ноду(контейнер, всю сеть,
>etc) - и указываете, какой пекедж надо туда поставить. Всё делается
>из одной точки. Причем, агент для win32/x86 не будет наложен на
>Solaris, скажем.А вот это вообще не должно входит в обязанности системы мониторинга. Посмотри в стандарты ITSM или MOF там четко описан процесс Configuration Management. Соответственно на предприятии предпочтительно иметь одну систему управления ПО и конфигураций а не ворох от каждого производителя.
>www.nagios.org. нормальная система мониторинга промышленного уровня. Все сказанное про NetXMS делает с
>успехом, а то и больше.
Эта штука нифига не промышленного уровня. К тому же nagios это просто система регистрации событий и не более того.
>>www.nagios.org. нормальная система мониторинга промышленного уровня. Все сказанное про NetXMS делает с
>>успехом, а то и больше.
>Эта штука нифига не промышленного уровня. К тому же nagios это просто
>система регистрации событий и не более того.
http://www.nagios.org/userprofiles/search.php?search=1. неполный список организаций ислоьзующих нагиос.
нагиос не только регистрации событий. у него есть такое понятие как event handler,Event handlers are optional commands that are executed whenever a host or service state change occurs. An obvious use for event handlers (especially with services) is the ability for Nagios to proactively fix problems before anyone is notified. Another potential use for event handlers might be to log service or host events to an external database.
есть еще много фич невидных сначала.
>http://www.nagios.org/userprofiles/search.php?search=1. неполный список организаций ислоьзующих нагиос.
>нагиос не только регистрации событий. у него есть такое понятие как event
>handler,
Для тех кто в танке поясняю. Оно не УМЕЕТ само высчитыавать на показании каких либо данных генерировать какие либо тревоги. Оно умеет только регистировать события от плагинов. В связи с чем использование nagios в среде где у вас много устройств с SNMP превращается в pain in ass. К тому же отказ от использования СУБД положительно на масштабируемости не сказывается.
>Для тех кто в танке поясняю. Оно не УМЕЕТ само высчитыавать на
>показании каких либо данных генерировать какие либо тревоги. Оно умеет только
>регистировать события от плагинов. В связи с чем использование nagios в
>среде где у вас много устройств с SNMP превращается в pain
>in ass.
Хоть я и не сторонник нагиоса, но если у нас мало устройств с SNMP? ;)
>К тому же отказ от использования СУБД положительно на масштабируемости не сказывается.
все за свое.....
для тебя СУБД - это именно SQL? :)
открою тебе глаза: у нагиоса есть свой метод хранения полученных данных.
Хранением нужно управлять и он это делает. Кто сказал, что в нагиосе нет СУБД? :)
Ну а если ты все же про SQL - то я уже писал что универсальность обратнопропорциональна скорости.
О проблемах некой универсальной СУБД (аля мускуль, постгрес) тут уже кто-то писал, что локи на таблицы делают такое решение плохо масштабируемым или попросту говоря тормознутым (почти как Giant Lock во бзде ;).
>Хоть я и не сторонник нагиоса, но если у нас мало устройств
>с SNMP? ;)
Если у вас их мало и вас устраивают все плагины нагиоса юзайте.>для тебя СУБД - это именно SQL? :)
Для меня СУБД это система управления базами данных. И они как-то чаще всего бывают реляционными.>открою тебе глаза: у нагиоса есть свой метод хранения полученных данных.
А мужики то не знают! И что оно там хранит и как? Нативно оно само умеет писать только журнал событий и не более. Все графики приделываются сторонними средствами и хранят данные в отдельных rrd базах.>Хранением нужно управлять и он это делает. Кто сказал, что в нагиосе
>нет СУБД? :)
А что у нас журнал событий уже стал СУБД?>Ну а если ты все же про SQL - то я
>уже писал что универсальность обратнопропорциональна скорости.
То-то все реляционные СУБД используют.>О проблемах некой универсальной СУБД (аля мускуль, постгрес) тут уже кто-то писал,
>что локи на таблицы делают такое решение плохо масштабируемым или попросту
>говоря тормознутым (почти как Giant Lock во бзде ;).
Читайте выше. Локи на таблицы есть только в MySQL при использовании движка MyISAM. В случае использования InnoDB этого НЕ ПРОИСХОДИТ. Во всех других СУБД более серьезных СУБД этого нет уже очень давно. Транзакции рулят. К тому же у меня сейчас используется zabbix с СУБД mysql база весит 23 гига. Работает все хорошо и быстро. Что я не так делаю?
>>для тебя СУБД - это именно SQL? :)
>Для меня СУБД это система управления базами данных.
Труъ. Для меня тоже, как ни странно :)
>И они как-то чаще всего бывают реляционными.
Внимательно читаем определение СУБД (можно с вики) и понимаем, что
СУБД бывают не только реляционными... Так что "чаще всего" - это как-то не то ;)>>открою тебе глаза: у нагиоса есть свой метод хранения полученных данных.
>А мужики то не знают! И что оно там хранит и как?
>Нативно оно само умеет писать только журнал событий и не более.
Я хочу сказать, что нельзя утверждать, что в нагиосе нет СУБД.
Вот список основных функций СУБД:
http://ru.wikipedia.org/wiki/%D0%A1%D0%B...
-----CUT-------
* управление данными во внешней памяти (на дисках);
* управление данными в оперативной памяти;
* журнализация изменений и восстановление базы данных после сбоев;
* поддержание языков БД (язык определения данных, язык манипулирования данными).
-----/CUT-------
Внешний файл лога: читай, пиши - делай что угодно. Но функционал нацелен на добавление - что и происходит.
Управление в оперативной памяти - легко: получение кода возврата от плагина и передача кода в нужные функции-обработчики.
Журнал и восстановление: практически сложены на файловую систему, упростившись до сискола fsync() после кажой записи в лог.
Внутренний язык - конфиг :)
>Все графики приделываются сторонними средствами и хранят данные в отдельных rrd
>базах.
А кто говорил про сторонние графики? Конечно они чем-то другим рисуються :)
>А что у нас журнал событий уже стал СУБД?
Ну так - да :) По определениям СУБД - см. выше.
Очень заточенная под определенные вещи СУБД.
>То-то все реляционные СУБД используют.
Гибкость в наше время нужнее чем скорость. Тяжело под каждый проект свою СУБД писать...
Для нагиоса это сделано как минимум потому что там она очень проста.
>>О проблемах некой универсальной СУБД (аля мускуль, постгрес) тут уже кто-то писал,
>>что локи на таблицы делают такое решение плохо масштабируемым или попросту
>>говоря тормознутым (почти как Giant Lock во бзде ;).
>Читайте выше. Локи на таблицы есть только в MySQL при использовании движка
>MyISAM. В случае использования InnoDB этого НЕ ПРОИСХОДИТ. Во всех других
>СУБД более серьезных СУБД этого нет уже очень давно. Транзакции рулят.
>К тому же у меня сейчас используется zabbix с СУБД mysql
>база весит 23 гига. Работает все хорошо и быстро. Что я
>не так делаю?OMG. 23giga база мониторинга... %))))
Нет, ниче не хочу сказать. Не знаю на сколько это сервисов и за какое время.
Ну а про локи лишь с мускулем без транзикций - не буду спорить :)
>Внимательно читаем определение СУБД (можно с вики) и понимаем, что
>СУБД бывают не только реляционными... Так что "чаще всего" - это как-то
>не то ;)
А мужики то не знают!>Я хочу сказать, что нельзя утверждать, что в нагиосе нет СУБД.
В том виде что она есть сейчас она меня мало устраивает.>Внешний файл лога: читай, пиши - делай что угодно. Но функционал нацелен
>на добавление - что и происходит.
>Управление в оперативной памяти - легко: получение кода возврата от плагина и
>передача кода в нужные функции-обработчики.
>Журнал и восстановление: практически сложены на файловую систему, упростившись до сискола fsync()
>после кажой записи в лог.
>Внутренний язык - конфиг :)
Функционал мал. Если его хватает, то хорошо. Но когда нет, то nagios превращается в головную боль.>А кто говорил про сторонние графики? Конечно они чем-то другим рисуються :)
Ну вообще система мониторинга должна не только тревоги регистирировать. Желательно, чтобы она еще умела к примеру графики рисовать на основе полученных данных.>Гибкость в наше время нужнее чем скорость. Тяжело под каждый проект свою
>СУБД писать...
Ну еще надо не забывать, что реляционные СУБД дают неплохую скорость. Особенно при конкуретном доступе к данным.>Для нагиоса это сделано как минимум потому что там она очень проста.
Ага в результате расширение функционала выливается в головную боль.>OMG. 23giga база мониторинга... %))))
>Нет, ниче не хочу сказать. Не знаю на сколько это сервисов и
>за какое время.
1587 items. За полгода.
>>Внутренний язык - конфиг :)
>Функционал мал. Если его хватает, то хорошо. Но когда нет, то nagios
>превращается в головную боль.Какое там добавление функционала.
Локализацию на любой язык кроме английского приходится с такими мучениями делать что никто уже давно не берется за это. А все потому что разработчик в одиночку изобретает свой велосипед с уникальными квадратными колесами и не собирается ничего менять.
>>http://www.nagios.org/userprofiles/search.php?search=1. неполный список организаций ислоьзующих нагиос.
>>нагиос не только регистрации событий. у него есть такое понятие как event
>>handler,
>Для тех кто в танке поясняю. Оно не УМЕЕТ само высчитыавать на
>показании каких либо данных генерировать какие либо тревоги. Оно умеет только
>регистировать события от плагинов. В связи с чем использование nagios в
>среде где у вас много устройств с SNMP превращается в pain
>in ass. К тому же отказ от использования СУБД положительно на
>масштабируемости не сказывается.ИМХО классическая система Fault management каковой Nagios является по стандартам tmforum не должна уметь что то там высчитывать.
Вычислением цифровых показателей и проверкой числовых порогов должна заниматься система Perfomance management. C случае нарущения порога она должна генерировать аварийное сообщение и отдавает его в Fault management.
>>Эта штука нифига не промышленного уровня. К тому же nagios это просто
>>система регистрации событий и не более того.
>
>http://www.nagios.org/userprofiles/search.php?search=1. неполный список организаций ислоьзующих нагиос.Ну это вообще ни разу не доказательство качества программы. 300 миллионов лемингов не могут ошибаться! Nagios так же использует AOL или Связьинвест. И что с того?
На рынке побеждает не тот кто лучше продукт выпускает, а тот кто пришел первым и у кого маркетинг лучше!!
Стоит отметить что лет 5 назад Nagios был системой очень даже хорошего уровня. Но ничто под луной не вечно.
Посмотрите на досуге Zenoss, OpenNMS
Я думаю что интересно как Web-интерфейс (хотя бы возможность отчётов и сигнализации проблем) так и нативная консоль под Линукс.
Кстати, кто нибудь может подсказать софт, который мониторит аппаратные конфигурации? К сожалению под *nix я таких не видел, либо плохо искал. Zabbix и Nagios мониторят только состояния, эта система тоже. Очень сильно не хватает собирать централизовано информацию о конфигурациях компьютеров.
>Кстати, кто нибудь может подсказать софт, который мониторит аппаратные конфигурации? К сожалению
>под *nix я таких не видел, либо плохо искал. Zabbix и
>Nagios мониторят только состояния, эта система тоже. Очень сильно не хватает
>собирать централизовано информацию о конфигурациях компьютеров.
OCSInventory попробуй.
>>Кстати, кто нибудь может подсказать софт, который мониторит аппаратные конфигурации? К сожалению
>>под *nix я таких не видел, либо плохо искал. Zabbix и
>>Nagios мониторят только состояния, эта система тоже. Очень сильно не хватает
>>собирать централизовано информацию о конфигурациях компьютеров.
>
>
>OCSInventory попробуй.mozhet RANCID?
>>>Кстати, кто нибудь может подсказать софт, который мониторит аппаратные конфигурации? К сожалению
>>>под *nix я таких не видел, либо плохо искал. Zabbix и
>>>Nagios мониторят только состояния, эта система тоже. Очень сильно не хватает
>>>собирать централизовано информацию о конфигурациях компьютеров.
>>
>>
>>OCSInventory попробуй.
>
>mozhet RANCID?У Zabbix с этим большие проблемы. Планируется ли как-то усовершенствовать работу с trap-ами?
Огромное спасибо, думаю это то что надо.