NCM (http://www.chris.ru/dev/netcm.php) ( Network common monitor ) является системой мониторинга сети, с открытым кодом. Преимущества системы, помимо открытости кода, является гибкость, например, если хочется заниматься мониторингом стойки, нарисуйте стойку и мониторьте.
В настоящее время реализованы:
- Мониторинг серверов
- Мониторинг BGP пиров
- Мониторинг BGP сессий
- Построение статистики сети (визуальный мониторинг групп хостов)
- Работа с оборудованием Cisco Systems
URL: http://www.chris.ru/dev/netcm.php
Новость: https://www.opennet.ru/opennews/art.shtml?num=5581
Идея конечно хорошая, но к сожалению уровень реализации достаточно низок. Особенно поразили строки вида:system("cat /usr/BGP_MONITOR/log/".$hostname.".log | grep 192.168.| grep 192.168.| grep -v \"router identifier\" > /usr/BGP_MONITOR/log/".$hostname...
<meta http-equiv="Content-Type" content="text/html; charset=windows-1251">
$authloginrequst = @mysql_query("SELECT * FROM users WHERE login ='$PHP_AUTH_USER' AND parol like '$PHP_AUTH_PW';");
<p align="center"><font color="#FFFFFF" size="1" face="Verdana, Arial, Helvetica, sans-serif">дНАПН ОНДЮКНБЮРЭ Б<br>
и тд.так что даже до уровня nagios очень далеко
Советую:
* прорабодать (продумать) объектную модель, реализовать базовые абстракные классы для мониторинга, сбора статистики, отображения, оповещения и тд., а уже от них наследовать и дать возможность написания своих плагинов на этом фундаменте
* не привязываться к какой-то конкретной БД
* абстрактно подходить к каждому объекту мониторинга ( а не 'mysql_query("INSERT INTO neighbors (neighbor,aserv,version,neias,recv,xmit,uptime,state)...'
* использовать smarty, или другой инструмент шаблонов (
* конечно css отдельно, i18n
* сразу продумать поддержку уровней (типа: стойка, локальная сеть подразделения, предприятия, района, города, области, etc)
* открытие Trouble Ticket'а (TT)
* эскалация (оповещение сотрудников рангом выше, в зависимости от того как быстро решается TT)
* да и для начала взять все хорошие идеи из nagios
* надо еще подумать...Конечно, это мои мысли про идеальную систему мониторинга, которой наверно не будет никогда:
PS: все это имхо, и надеюсь будет воспринято как конструктивная критика.
>Идея конечно хорошая, но к сожалению уровень реализации достаточно низок.
Посмотрите zabbix
>так что даже до уровня nagios очень далеко
До уровня zabbix еще дальше. Пока nagios не будет нативно складывать данные в СУБД, говорить о nagios как о хорошей системе мониторинга собственно нельзя.> * прорабодать (продумать) объектную модель, реализовать базовые абстракные классы для
>мониторинга, сбора статистики, отображения, оповещения и тд., а уже от них
В целом да.
>наследовать и дать возможность написания своих плагинов на этом фундаменте
Лучше опираться на данные, а не на статусы. Это гибче и спецификация на плагины и агенты становится проще.> * не привязываться к какой-то конкретной БД
Да это бы не плохо плюс лучше все что можно сделать в СУБД, а это автоматически подразумевает SQL-92.> * абстрактно подходить к каждому объекту мониторинга
хм... ну в целом в zabbix используется аналогичный подход.> * использовать smarty, или другой инструмент шаблонов
для frontend ? Мое IMHO struts> * конечно css отдельно, i18n
ну это то понятно хотя в целом не особо необходимо.> * сразу продумать поддержку уровней (типа: стойка, локальная сеть подразделения,
>предприятия, района, города, области, etc)
Группы и деревья. Ну это то понятно. В zabbix есть подобное, но пока первого уровня.> * открытие Trouble Ticket'а (TT)
это называется тревоги в zabbix
> * эскалация (оповещение сотрудников рангом выше, в зависимости от того
>как быстро решается TT)
действия в zabbix> * да и для начала взять все хорошие идеи из nagios
А что хорошего в nagios ? Кроме его популярности?
>А что хорошего в nagios ? Кроме его популярности?
А чего в nagios, кроме отсутсвия более активной работы с БД, если так можно выразится, плохого?
P.S.
А вообще-то хочется узнать мнение уважаемого all'а о Nagios vs. Zabbix.
>А чего в nagios, кроме отсутсвия более активной работы с БД, если так можно выразится, плохого?1. Плагины отдают статусы.
С одной стороны это хорошо... Но с другой стороны это плохо. Особенно тем что если надо что-то поменять надо рыться в коде плагина. Хорошо же это в случае сложного алгоритма обработки. Хотя опять же раз отдается статус, то мы получаем меньше данных и их проще обрабатывать. В zabbix же все значения. За счет этого проще писать плагины.2. Нет СУБД.
По сути дела, она она особо и не нужна при архитектуре nagios. Теперь вспомним про apan и его интеграцию с nagios. В zabbix же сбор статистики уже включен так как это требуется для срабатывания тревог. И эти данные можно обрабатывать как угодно.3. Отсутствие нативной поддержки SNMP.
Это убивает nagios как систему мониторинга, для сетей с большим количеством оборудования с поддержкой SNMP. Слишком накладно становится плодить плагины.4. Frontend к zabbix может быть любой.
> Посмотрите zabbix
уже смотрю, года 3 назад - когда я выбирал nms, его небыло>> * использовать smarty, или другой инструмент шаблонов
>для frontend ? Мое IMHO struts
согласен, можно и struts
>> * да и для начала взять все хорошие идеи из nagios
>А что хорошего в nagios ? Кроме его популярности?
я имел в виду: взять все хорошие идеи из существующих систем: mon, nagios, opennms, zabbix, (и еще какаято на php писанная), etc
>уже смотрю, года 3 назад - когда я выбирал nms, его небыло
OpenNMS ? Который на жабе писан ?
NMS=network managment (monitoring) system
сначала жил на mon и не жаловался, но потом меня убедили перейти на nagios
Господа, я писал систему не чтобы составить конкуренцию тому же Nagios, т.к. сам пользуюсь и им (про zabix молчу, говно говном), но сделать систему более менее real time мониторинга, например мониторится доступность поточно. Потом это всего лишь первый стабильный релиз программы, который стоит всего у нескольких провайдеров, да сейчас есть недостатки и недописки (например поддержки цисок пока нет и поддержки различный паролей от зебры тоже), но оно уже тестируется. Насчет привязки к базе, тогда давайте складывать в пямять запросы и транзакцией их отправлять в Oracle (Pg, Firebird adn etc), но смысл использовать тяжелую базу для легких запросов? Потом нагион пока проверит доступность хоста... как говорить и царь умрёт, здесь же всё более менее четко. Ещё раз оговорюсь, что принимаю все пожелания на разработку и всё же хочу продукт доделать до нужного уровня, о котором действительно говорить пока рановато, с чем я согласен.Удачи!
>Господа, я писал систему не чтобы составить конкуренцию тому же Nagios, т.к. сам пользуюсь и им (про zabix молчу, говно говном)
Тааак кто-то решил покидаться грязью хорошо... Тогда простой вопрос. Как мне сделать проверку хоста на доступность с шагом проверки в 30 секунд и срабатыванием в случае недоступности хоста в течении 2 минут? Написать плагин к nagios? Или как ? В zabbix это делается штатными методами за 2 минуты. Так что сначала обоснуйте то, что zabbix дерьмо.>Насчет привязки к базе, тогда давайте складывать в пямять запросы и транзакцией их отправлять в Oracle (Pg, Firebird adn etc), но смысл использовать тяжелую базу для легких запросов?
В том что в этом случае мы получаем гибкое окружение для манипулирования данными. А в случае хостов числом более 200 и сервисов на каждом около 10 обработка всего этого nagios будет жрать огого.>Потом нагион пока проверит доступность хоста... как говорить и царь умрёт, здесь же всё более менее четко.
Это назвается скорость реакции смотрите выше пример. У nagios'а большая латентность.
>Тааак кто-то решил покидаться грязью хорошо... Тогда простой вопрос. Как мне сделать
>проверку хоста на доступность с шагом проверки в 30 секунд и
>срабатыванием в случае недоступности хоста в течении 2 минут? Написать плагин
>к nagios? Или как ? В zabbix это делается штатными методами
>за 2 минуты. Так что сначала обоснуйте то, что zabbix дерьмо.
>
>
interval_length=30
а потом или max_check_attempts или sertvice escalation смотреть, вроде не проблема совсем ;)
>В том что в этом случае мы получаем гибкое окружение для манипулирования
>данными. А в случае хостов числом более 200 и сервисов на
>каждом около 10 обработка всего этого nagios будет жрать огого.
>
а реальные цифры есть?
>Это назвается скорость реакции смотрите выше пример. У nagios'а большая латентность.
service_reaper_frequency ?
не "sertvice escalation", notification escalations, вот.
>interval_length=30
>а потом или max_check_attempts или sertvice escalation смотреть, вроде не проблема совсем
Насколько я понял предлагается выставить нужный интервал и через сколько неудачных попыток подавать сигнал. Офигенно удобно.>>В том что в этом случае мы получаем гибкое окружение для манипулирования
>>данными. А в случае хостов числом более 200 и сервисов на
>>каждом около 10 обработка всего этого nagios будет жрать огого.
2000 сервисов. Пусть статус опрашивается раз в 30 секунд. Будем прикидывать какой длины будет лог ?>service_reaper_frequency ?
а потом на каждый сервис настраивать сколько тревог пропускать ? Очень удобно.
>Насколько я понял предлагается выставить нужный интервал и через сколько неудачных попыток подавать сигнал. Офигенно удобно.
хммм.... что именно не удобно? если interval_length задать в 1, то для каждого сервиса/хоста интервал проверки можно задать с точностью до секунды. Не удобно, но точно. Удобно interval_length задать в минимально нужный делитель, например 10 или 5, я упрощаю, тут http://nagios.sourceforge.net/docs/2_0/checkscheduling.html подробнее.
>2000 сервисов. Пусть статус опрашивается раз в 30 секунд. Будем прикидывать какой длины будет лог ?
В лог пишется, по умолчанию, только при событии, лог не будет большим пока все ОК ;)
>а потом на каждый сервис настраивать сколько тревог пропускать ? Очень удобно.
Нет, надо normal_check_inteval, для остальных поднять, если interval_length маленький.
>хммм.... что именно не удобно? если interval_length задать в 1, то для >каждого сервиса/хоста интервал проверки можно задать с точностью до >секунды. Не удобно, но точно. Удобно interval_length задать в минимально >нужный делитель, например 10 или 5, я упрощаю, тут >http://nagios.sourceforge.net/docs/2_0/checkscheduling.html подробнее.
именно это то и не удобно... в zabbix используется иная идеология проверки. В триггерах проверяются данные и функции от данных. Интервал срабатывания не зависит от интервала проверки. Т.е. к примеру если я меняю его с 30 секунд на 20 секунд то в nagios сработка будет происходить через 40 секунд. А в zabbix как и было т.е. через минуту.>В лог пишется, по умолчанию, только при событии, лог не будет большим пока все ОК ;)
А теперь добавляем графики и apan.>Нет, надо normal_check_inteval, для остальных поднять, если interval_length маленький
угу очень удобно проверка проверок.
>именно это то и не удобно... в zabbix используется иная идеология проверки.
>В триггерах проверяются данные и функции от данных. Интервал срабатывания не
>зависит от интервала проверки. Т.е. к примеру если я меняю его
>с 30 секунд на 20 секунд то в nagios сработка будет
>происходить через 40 секунд. А в zabbix как и было т.е.
>через минуту.
>сработка?? как все сложно ;) не понимаю, честно
>>В лог пишется, по умолчанию, только при событии, лог не будет большим пока все ОК ;)
>А теперь добавляем графики и apan.
>Не знаю, не юзал пока, но на скока читал perfparse, можно сразу данные заганять в базу.
>>Нет, надо normal_check_inteval, для остальных поднять, если interval_length маленький
>угу очень удобно проверка проверок.какая такая "проверка проверок" ????
normal_check_inteval - число interval_length между проверками.
>сработка?? как все сложно ;) не понимаю, честно
ну ваши проблемы. Просто триггер может работать как от тупого статуса или уровня, а может от уже полученных данных к примеру при повышении средней нагрузки на 10 процентов.>Не знаю, не юзал пока, но на скока читал perfparse, можно сразу
>данные заганять в базу.
Ага получаемая строка кормится вызываемому скрипту в виде exec так что фиг а не база.>какая такая "проверка проверок" ????
>normal_check_inteval - число interval_length между проверками.
Т.е. 30 секунд к примеру далее чтобы порог срабатывания был от двух неверных статусов это надо еще дополнительно настроить.
>ну ваши проблемы. Просто триггер может работать как от тупого статуса или уровня, а может от уже полученных данных к примеру при повышении средней нагрузки на 10 процентов.
интересно.>Ага получаемая строка кормится вызываемому скрипту в виде exec так что фиг а не база.
код не смотрел, поэтому сомнения на счет exec'a.
>Т.е. 30 секунд к примеру далее чтобы порог срабатывания был от двух неверных статусов это надо еще дополнительно настроить.
да, надо retry_check_interval указать и max_check_attempts тоже, если в темпейте не задано, notification escalations немного для другого.
>код не смотрел, поэтому сомнения на счет exec'a.
Я смотрел. Поэтому знаю что говорю.>да, надо retry_check_interval указать и max_check_attempts тоже, если в темпейте не задано,
>notification escalations немного для другого.
Офигительно удобно :) больше тут сказать нечего.
>>да, надо retry_check_interval указать и max_check_attempts тоже, если в темпейте не задано,
>>notification escalations немного для другого.
>Офигительно удобно :) больше тут сказать нечего.
А что неудобого? сделал пяток темплейтов всего-то.Performance данные в базу можно загонять в batch режиме, если реально надо realtime performance мониторинг, нужны другие проги (cacti?). Nagios не лишен недостатков, но заявки "У nagios'а большая латентность" довольно странны.
>А что неудобого? сделал пяток темплейтов всего-то.
С моей точки зрения много гемороя.>Performance данные в базу можно загонять в batch режиме, если реально надо realtime performance мониторинг, нужны другие проги (cacti?).
Так это система мониторинга или система уведомлений? Если таки система мониторинга то желательно чтоб все было вместе.>Nagios не лишен недостатков, но заявки "У nagios'а большая латентность" довольно странны.
1. По умолчанию проверки выполняются раз в 5 минут. У zabbix умолчание 30 секунд.
2. Еще раз повторю имеется большая латентность. Реально то чо вы привели должно использоваться в случае не критичности пары сбоев и для связки с другими событиями. Кроме этого при наличии apan и интервалах проверки в 30 секунд nagios будет жрать много ресурсов, хотя только в этом варианте он становится аналогом zabbix.
На счет Zabbix сказать не могу. Хотя походу без Х-ов он не живет.
Nagios же штука отработаная. Содержит массу плагинов, под спец. железо масса написанных скриптов. Хош отдельно плагины используй, по крону и пиши в логи. Хош в составе основной программы. Для работы с SNMP используется всего один плагин "check_snmp" (надо тока уметь им пользоваться). Можно воспользоваться прогр. из комплекта NET-SNMP они прекрасно интегрируются. Большие возможности по отправке уведомлений (можно использовать любые внешние программы). Прекрасно интегрируется с MRTG,RRDtool,Cacti. У некоторых и в MySQL все складывает. Все бы хорошо. Но конечно не без проблемм. Веб интерфейс слабоват, возможность репортов проработана не до конца. Нет внутренних средств для распределения доступа в веб к определенным группам хостов, сервисов. Можно запустить несколько процессов. Со своими логами, настройками. Тока CGI скрипты берут данные из одного status.log. Правка исходников и перекомпиляция не помогают.
Nagios слишком плохо работает с большой группой хостов... А у меня сетка приличная... И не только у меня, поэтому пришлось писать своё.
Много это сколько? Сколько хостов и сколько сервисов?Я тоже в свое время писал свое. Но зачем, если это Nagios делает не плохо.
Плохо это как, это что значит? Пропускает проверки, большая нагрузка?Сам на пути создания мониторинга, nagios выглядит наиболее многообещающе, легко сопрягается с другими пакетами, например с net-snmp для snmp-trap'ов и swatch/logwatch для отслеживания событий из syslog/eventlog'а. Заточен конечно для *nix, IMHO.
При всём моём уважении к автору, НО вы написали откровенную лабуду.Вы хоть пробовали её поставить перед тем как опубликовади архив? Думаю нет !!!
action.php глянте, сразу увидите баг в первых строчках, я не говорю уже о том как криво написан порт под FreeBSD.
Так что релизом тут и не пахнет !!!
Слишком всё пестро, а толку нет !!!
Карта сети вообще не работает !!!
Я бы такую лабуду даже и не решился публиковать....
в table.sql тоже гора ошибок, вы видать с синтаксисом SQL плохо знакомы !!!
Да и по поводу zabbix'a автор загнул.
>Карта сети вообще не работает !!!Тебе скриншот дать? У тебя наверное не хватило чего то поставить GD
table.sql :-))))))))))))
Ага, плохо его знает mysqldump :-)
Пробывал и нагиос и данное решение на нагрузке до 120 хостов. Попробуйте, посмотрите...
>Пробывал и нагиос и данное решение на нагрузке до 120 хостов. Попробуйте,
>посмотрите...
Вот что у меня (Dell PowerEdge 2600):
339 Matching Service Entries Displayed
117 Matching Host Entries DisplayedНо это как настроены normal_check_interval, ... (можно ведь и 10-ю севисами загнуть Nagios)
>>Пробывал и нагиос и данное решение на нагрузке до 120 хостов. Попробуйте,
>>посмотрите...про nagios %)
Host Status Totals: 160
Service Status Totals: 816живет все на P4 2.6mhz, 512ram, машину вообще не загружает.
Мониторю все в основном по snmp (cisco, lucent, linux)
Сетка региональная.
Претензий никаких к нему.
Есть только пожелания :), да и то, все что нужно - дописываю сам, без каких либо проблем :)
так что извините, но Nagios пока что рулит.
>про nagios %)
>
>Host Status Totals: 160
>Service Status Totals: 816
>
>живет все на P4 2.6mhz, 512ram, машину вообще не загружает.
>Мониторю все в основном по snmp (cisco, lucent, linux)
>Сетка региональная.
>Претензий никаких к нему.
>Есть только пожелания :), да и то, все что нужно - дописываю
>сам, без каких либо проблем :)
>так что извините, но Nagios пока что рулит.про zabbix
STATUS OF ZABBIX
Parameter Value
ZABBIX server is running Yes
Number of values stored 36905785
Number of trends stored 1488699
Number of alarms 5420
Number of alerts 10105
Number of triggers (enabled/disabled) 472(472/0)
Number of items (active/trapper/not active/not supported) 1551(1404/75/1/146)
Number of users 4
Number of hosts (monitored/not monitored/templates) 71(63/8/0)так что вы там говорили про nagios ?
>так что вы там говорили про nagios ?
То, что он, в моем варианте, меня устраивает более чем :)
Я не навязываю, я предлагаю, просто кому т оэто решение будет намного удобнее.
>Я не навязываю, я предлагаю, просто кому т оэто решение будет намного
>удобнее.
А ведь Sauron прав! Я бы тоже хотел увидеть конструктивную критику в адрес zabbix, отличающуюся (конструктивностью) от "говно говном". Уж договаривайте, раз уж на то пошло, а то вот мониторим заббиксом, а оно говно окажется... Враз перееду на Вашу или на Nagios.
Пользуюсь пакетом scotty, не просто система мониторинга, а менеджмента сетей. Смотрю на открытые системы мониторинга, даже до функционала tkined (часть scotty) им далеко.
p.s. Желающие оспорить моё мнение, милости просим рассказать задачу, и показать скриншотом её у вас. Посмотрим, на самом деле я ошибаюсь, или нет.
а он web-based ?
дело в том, что я хочу видеть положение вещей и на работе, и дома, и в машине, и на винде и на линуксе
>Пользуюсь пакетом scotty, не просто система мониторинга, а менеджмента сетей. Смотрю на
>открытые системы мониторинга, даже до функционала tkined (часть scotty) им далеко.Это ? http://wwwhome.cs.utwente.nl/~schoenw/scotty/#OVERVIEW
1. нет веб интерфейса
2. непонятно использует ли СУБД
3. использование tcl мне не шибко нравится хотя это уже IMHO
4. а где мониторинг ?
cacti ВАС спасет мир
>cacti ВАС спасет мирcacti только графики рисует.
Могу предложить другое решение - OpenNMS.
WEB-интерфейс. Мониторинг доступности сервисов (HTTP,SMTP,POP3,DNS) и хостов(по ICMP). Сбор статистики по SNMP (от UPS-ки до Cisco-маршрутизаторов ). Хранение статистики и отрисовка графиков c использованием rrd-tools(развитие пакета MRTG).
Настройка нотификаций с єкскалацией по SNMP-trap событию и по исчезновению сервиса/хоста.
Гибкие настройки в XML.
Ведение инветарной базы оборудовния.
Кофе не варит:)
>Могу предложить другое решение - OpenNMS.
>WEB-интерфейс. Мониторинг доступности сервисов (HTTP,SMTP,POP3,DNS) и хостов(по ICMP). Сбор статистики по
>SNMP (от UPS-ки до Cisco-маршрутизаторов ). Хранение статистики и отрисовка графиков
>c использованием rrd-tools(развитие пакета MRTG).
>Настройка нотификаций с єкскалацией по SNMP-trap событию и по исчезновению сервиса/хоста.
>
>Гибкие настройки в XML.
>Ведение инветарной базы оборудовния.
пробовал жрет много ресурсов и заточено только под tomcat