| 1.1, Vlad (??), 23:27, 06/06/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Идея конечно хорошая, но к сожалению уровень реализации достаточно низок. Особенно поразили строки вида:
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: все это имхо, и надеюсь будет воспринято как конструктивная критика.
| | |
| |
| 2.2, sauron (ok), 06:56, 07/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
 >Идея конечно хорошая, но к сожалению уровень реализации достаточно низок.
Посмотрите zabbix
>так что даже до уровня nagios очень далеко
До уровня zabbix еще дальше. Пока nagios не будет нативно складывать данные в СУБД, говорить о nagios как о хорошей системе мониторинга собственно нельзя.
> * прорабодать (продумать) объектную модель, реализовать базовые абстракные классы для
>мониторинга, сбора статистики, отображения, оповещения и тд., а уже от них
В целом да.
>наследовать и дать возможность написания своих плагинов на этом фундаменте
Лучше опираться на данные, а не на статусы. Это гибче и спецификация на плагины и агенты становится проще.
> * не привязываться к какой-то конкретной БД
Да это бы не плохо плюс лучше все что можно сделать в СУБД, а это автоматически подразумевает SQL-92.
> * абстрактно подходить к каждому объекту мониторинга
хм... ну в целом в zabbix используется аналогичный подход.
> * использовать smarty, или другой инструмент шаблонов
для frontend ? Мое IMHO struts
> * конечно css отдельно, i18n
ну это то понятно хотя в целом не особо необходимо.
> * сразу продумать поддержку уровней (типа: стойка, локальная сеть подразделения,
>предприятия, района, города, области, etc)
Группы и деревья. Ну это то понятно. В zabbix есть подобное, но пока первого уровня.
> * открытие Trouble Ticket'а (TT)
это называется тревоги в zabbix
> * эскалация (оповещение сотрудников рангом выше, в зависимости от того
>как быстро решается TT)
действия в zabbix
> * да и для начала взять все хорошие идеи из nagios
А что хорошего в nagios ? Кроме его популярности?
| | |
| |
| 3.3, dim (??), 09:59, 07/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
>А что хорошего в nagios ? Кроме его популярности?
А чего в nagios, кроме отсутсвия более активной работы с БД, если так можно выразится, плохого?
P.S.
А вообще-то хочется узнать мнение уважаемого all'а о Nagios vs. Zabbix. | | |
| |
| 4.16, sauron (??), 19:23, 07/06/2005 [^] [^^] [^^^] [ответить]
| +/– | |
>А чего в nagios, кроме отсутсвия более активной работы с БД, если так можно выразится, плохого?
1. Плагины отдают статусы.
С одной стороны это хорошо... Но с другой стороны это плохо. Особенно тем что если надо что-то поменять надо рыться в коде плагина. Хорошо же это в случае сложного алгоритма обработки. Хотя опять же раз отдается статус, то мы получаем меньше данных и их проще обрабатывать. В zabbix же все значения. За счет этого проще писать плагины.
2. Нет СУБД.
По сути дела, она она особо и не нужна при архитектуре nagios. Теперь вспомним про apan и его интеграцию с nagios. В zabbix же сбор статистики уже включен так как это требуется для срабатывания тревог. И эти данные можно обрабатывать как угодно.
3. Отсутствие нативной поддержки SNMP.
Это убивает nagios как систему мониторинга, для сетей с большим количеством оборудования с поддержкой SNMP. Слишком накладно становится плодить плагины.
4. Frontend к zabbix может быть любой.
| | |
|
| 3.8, Vlad (??), 12:05, 07/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
> Посмотрите zabbix
уже смотрю, года 3 назад - когда я выбирал nms, его небыло
>> * использовать smarty, или другой инструмент шаблонов
>для frontend ? Мое IMHO struts
согласен, можно и struts
>> * да и для начала взять все хорошие идеи из nagios
>А что хорошего в nagios ? Кроме его популярности?
я имел в виду: взять все хорошие идеи из существующих систем: mon, nagios, opennms, zabbix, (и еще какаято на php писанная), etc
| | |
| |
| 4.19, sauron (??), 19:41, 07/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
>уже смотрю, года 3 назад - когда я выбирал nms, его небыло
OpenNMS ? Который на жабе писан ? | | |
| |
| 5.20, Vlad (??), 00:29, 08/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
NMS=network managment (monitoring) system
сначала жил на mon и не жаловался, но потом меня убедили перейти на nagios | | |
|
|
|
|
| 1.4, Chris (??), 10:01, 07/06/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Господа, я писал систему не чтобы составить конкуренцию тому же Nagios, т.к. сам пользуюсь и им (про zabix молчу, говно говном), но сделать систему более менее real time мониторинга, например мониторится доступность поточно. Потом это всего лишь первый стабильный релиз программы, который стоит всего у нескольких провайдеров, да сейчас есть недостатки и недописки (например поддержки цисок пока нет и поддержки различный паролей от зебры тоже), но оно уже тестируется. Насчет привязки к базе, тогда давайте складывать в пямять запросы и транзакцией их отправлять в Oracle (Pg, Firebird adn etc), но смысл использовать тяжелую базу для легких запросов? Потом нагион пока проверит доступность хоста... как говорить и царь умрёт, здесь же всё более менее четко. Ещё раз оговорюсь, что принимаю все пожелания на разработку и всё же хочу продукт доделать до нужного уровня, о котором действительно говорить пока рановато, с чем я согласен.
Удачи! | | |
| |
| 2.17, sauron (??), 19:36, 07/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
>Господа, я писал систему не чтобы составить конкуренцию тому же Nagios, т.к. сам пользуюсь и им (про zabix молчу, говно говном)
Тааак кто-то решил покидаться грязью хорошо... Тогда простой вопрос. Как мне сделать проверку хоста на доступность с шагом проверки в 30 секунд и срабатыванием в случае недоступности хоста в течении 2 минут? Написать плагин к nagios? Или как ? В zabbix это делается штатными методами за 2 минуты. Так что сначала обоснуйте то, что zabbix дерьмо.
>Насчет привязки к базе, тогда давайте складывать в пямять запросы и транзакцией их отправлять в Oracle (Pg, Firebird adn etc), но смысл использовать тяжелую базу для легких запросов?
В том что в этом случае мы получаем гибкое окружение для манипулирования данными. А в случае хостов числом более 200 и сервисов на каждом около 10 обработка всего этого nagios будет жрать огого.
>Потом нагион пока проверит доступность хоста... как говорить и царь умрёт, здесь же всё более менее четко.
Это назвается скорость реакции смотрите выше пример. У nagios'а большая латентность.
| | |
| |
| 3.23, dim (??), 10:56, 08/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
>Тааак кто-то решил покидаться грязью хорошо... Тогда простой вопрос. Как мне сделать
>проверку хоста на доступность с шагом проверки в 30 секунд и
>срабатыванием в случае недоступности хоста в течении 2 минут? Написать плагин
>к nagios? Или как ? В zabbix это делается штатными методами
>за 2 минуты. Так что сначала обоснуйте то, что zabbix дерьмо.
>
>
interval_length=30
а потом или max_check_attempts или sertvice escalation смотреть, вроде не проблема совсем ;)
>В том что в этом случае мы получаем гибкое окружение для манипулирования
>данными. А в случае хостов числом более 200 и сервисов на
>каждом около 10 обработка всего этого nagios будет жрать огого.
>
а реальные цифры есть?
>Это назвается скорость реакции смотрите выше пример. У nagios'а большая латентность.
service_reaper_frequency ?
| | |
| |
| 4.26, dim (??), 11:03, 08/06/2005 [^] [^^] [^^^] [ответить]
| +/– | |
не "sertvice escalation", notification escalations, вот. | | |
| 4.28, sauron (ok), 11:31, 08/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
>interval_length=30
>а потом или max_check_attempts или sertvice escalation смотреть, вроде не проблема совсем
Насколько я понял предлагается выставить нужный интервал и через сколько неудачных попыток подавать сигнал. Офигенно удобно.
>>В том что в этом случае мы получаем гибкое окружение для манипулирования
>>данными. А в случае хостов числом более 200 и сервисов на
>>каждом около 10 обработка всего этого nagios будет жрать огого.
2000 сервисов. Пусть статус опрашивается раз в 30 секунд. Будем прикидывать какой длины будет лог ?
>service_reaper_frequency ?
а потом на каждый сервис настраивать сколько тревог пропускать ? Очень удобно. | | |
| |
| 5.30, dim (??), 12:08, 08/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
>Насколько я понял предлагается выставить нужный интервал и через сколько неудачных попыток подавать сигнал. Офигенно удобно.
хммм.... что именно не удобно? если interval_length задать в 1, то для каждого сервиса/хоста интервал проверки можно задать с точностью до секунды. Не удобно, но точно. Удобно interval_length задать в минимально нужный делитель, например 10 или 5, я упрощаю, тут http://nagios.sourceforge.net/docs/2_0/checkscheduling.html подробнее.
>2000 сервисов. Пусть статус опрашивается раз в 30 секунд. Будем прикидывать какой длины будет лог ?
В лог пишется, по умолчанию, только при событии, лог не будет большим пока все ОК ;)
>а потом на каждый сервис настраивать сколько тревог пропускать ? Очень удобно.
Нет, надо normal_check_inteval, для остальных поднять, если interval_length маленький. | | |
| |
| 6.31, sauron (ok), 12:24, 08/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
>хммм.... что именно не удобно? если 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 маленький
угу очень удобно проверка проверок.
| | |
| |
| 7.33, dim (??), 14:43, 08/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
>именно это то и не удобно... в zabbix используется иная идеология проверки.
>В триггерах проверяются данные и функции от данных. Интервал срабатывания не
>зависит от интервала проверки. Т.е. к примеру если я меняю его
>с 30 секунд на 20 секунд то в nagios сработка будет
>происходить через 40 секунд. А в zabbix как и было т.е.
>через минуту.
>
сработка?? как все сложно ;) не понимаю, честно
>>В лог пишется, по умолчанию, только при событии, лог не будет большим пока все ОК ;)
>А теперь добавляем графики и apan.
>
Не знаю, не юзал пока, но на скока читал perfparse, можно сразу данные заганять в базу.
>>Нет, надо normal_check_inteval, для остальных поднять, если interval_length маленький
>угу очень удобно проверка проверок.
какая такая "проверка проверок" ????
normal_check_inteval - число interval_length между проверками. | | |
| |
| 8.35, sauron (ok), 15:39, 08/06/2005 [^] [^^] [^^^] [ответить] | +/– | ну ваши проблемы Просто триггер может работать как от тупого статуса или уровня... текст свёрнут, показать | | |
| |
| 9.36, dim (??), 16:25, 08/06/2005 [^] [^^] [^^^] [ответить] | +/– | интересно код не смотрел, поэтому сомнения на счет exec a да, надо retry_check... текст свёрнут, показать | | |
| |
| |
| 11.38, dim (??), 13:34, 09/06/2005 [^] [^^] [^^^] [ответить] | +/– | А что неудобого сделал пяток темплейтов всего-то Performance данные в базу мож... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 3.42, Hotch (?), 16:30, 05/12/2005 [^] [^^] [^^^] [ответить]
| +/– |
На счет Zabbix сказать не могу. Хотя походу без Х-ов он не живет.
Nagios же штука отработаная. Содержит массу плагинов, под спец. железо масса написанных скриптов. Хош отдельно плагины используй, по крону и пиши в логи. Хош в составе основной программы. Для работы с SNMP используется всего один плагин "check_snmp" (надо тока уметь им пользоваться). Можно воспользоваться прогр. из комплекта NET-SNMP они прекрасно интегрируются. Большие возможности по отправке уведомлений (можно использовать любые внешние программы). Прекрасно интегрируется с MRTG,RRDtool,Cacti. У некоторых и в MySQL все складывает. Все бы хорошо. Но конечно не без проблемм. Веб интерфейс слабоват, возможность репортов проработана не до конца. Нет внутренних средств для распределения доступа в веб к определенным группам хостов, сервисов. Можно запустить несколько процессов. Со своими логами, настройками. Тока CGI скрипты берут данные из одного status.log. Правка исходников и перекомпиляция не помогают.
| | |
|
|
| 1.5, Chris (??), 10:02, 07/06/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Nagios слишком плохо работает с большой группой хостов... А у меня сетка приличная... И не только у меня, поэтому пришлось писать своё. | | |
| |
| 2.6, Artem (??), 11:20, 07/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
 Много это сколько? Сколько хостов и сколько сервисов?
Я тоже в свое время писал свое. Но зачем, если это Nagios делает не плохо. | | |
| 2.7, dim (??), 11:30, 07/06/2005 [^] [^^] [^^^] [ответить]
| +/– | |
Плохо это как, это что значит? Пропускает проверки, большая нагрузка?
Сам на пути создания мониторинга, nagios выглядит наиболее многообещающе, легко сопрягается с другими пакетами, например с net-snmp для snmp-trap'ов и swatch/logwatch для отслеживания событий из syslog/eventlog'а. Заточен конечно для *nix, IMHO. | | |
|
| 1.9, Григорьев Михаил (?), 13:23, 07/06/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 При всём моём уважении к автору, НО вы написали откровенную лабуду.
Вы хоть пробовали её поставить перед тем как опубликовади архив? Думаю нет !!!
action.php глянте, сразу увидите баг в первых строчках, я не говорю уже о том как криво написан порт под FreeBSD.
Так что релизом тут и не пахнет !!!
Слишком всё пестро, а толку нет !!!
Карта сети вообще не работает !!!
Я бы такую лабуду даже и не решился публиковать....
| | |
| 1.12, Chris (??), 14:08, 07/06/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Карта сети вообще не работает !!!
Тебе скриншот дать? У тебя наверное не хватило чего то поставить GD
table.sql :-))))))))))))
Ага, плохо его знает mysqldump :-) | | |
| 1.13, Chris (??), 14:09, 07/06/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Пробывал и нагиос и данное решение на нагрузке до 120 хостов. Попробуйте, посмотрите... | | |
| |
| 2.15, Artem (??), 15:04, 07/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
>Пробывал и нагиос и данное решение на нагрузке до 120 хостов. Попробуйте,
>посмотрите...
Вот что у меня (Dell PowerEdge 2600):
339 Matching Service Entries Displayed
117 Matching Host Entries Displayed
Но это как настроены normal_check_interval, ... (можно ведь и 10-ю севисами загнуть Nagios)
| | |
| |
| 3.18, Tigr (??), 19:37, 07/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
 >>Пробывал и нагиос и данное решение на нагрузке до 120 хостов. Попробуйте,
>>посмотрите...
про nagios %)
Host Status Totals: 160
Service Status Totals: 816
живет все на P4 2.6mhz, 512ram, машину вообще не загружает.
Мониторю все в основном по snmp (cisco, lucent, linux)
Сетка региональная.
Претензий никаких к нему.
Есть только пожелания :), да и то, все что нужно - дописываю сам, без каких либо проблем :)
так что извините, но Nagios пока что рулит. | | |
| |
| 4.21, sauron (ok), 06:36, 08/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
>про 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 ? | | |
| |
| 5.22, Tigr (??), 10:41, 08/06/2005 [^] [^^] [^^^] [ответить]
| +/– | |
>так что вы там говорили про nagios ?
То, что он, в моем варианте, меня устраивает более чем :)
| | |
|
|
|
|
| 1.14, Chris (??), 14:09, 07/06/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Я не навязываю, я предлагаю, просто кому т оэто решение будет намного удобнее. | | |
| |
| 2.25, Аноним (-), 10:58, 08/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
>Я не навязываю, я предлагаю, просто кому т оэто решение будет намного
>удобнее.
А ведь Sauron прав! Я бы тоже хотел увидеть конструктивную критику в адрес zabbix, отличающуюся (конструктивностью) от "говно говном". Уж договаривайте, раз уж на то пошло, а то вот мониторим заббиксом, а оно говно окажется... Враз перееду на Вашу или на Nagios. | | |
|
| 1.24, bass (??), 10:57, 08/06/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Пользуюсь пакетом scotty, не просто система мониторинга, а менеджмента сетей. Смотрю на открытые системы мониторинга, даже до функционала tkined (часть scotty) им далеко.
p.s. Желающие оспорить моё мнение, милости просим рассказать задачу, и показать скриншотом её у вас. Посмотрим, на самом деле я ошибаюсь, или нет.
| | |
| |
| 2.27, anonym (?), 11:30, 08/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
 а он web-based ?
дело в том, что я хочу видеть положение вещей и на работе, и дома, и в машине, и на винде и на линуксе | | |
| 2.29, sauron (ok), 11:35, 08/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
>Пользуюсь пакетом scotty, не просто система мониторинга, а менеджмента сетей. Смотрю на
>открытые системы мониторинга, даже до функционала tkined (часть scotty) им далеко.
Это ? http://wwwhome.cs.utwente.nl/~schoenw/scotty/#OVERVIEW
1. нет веб интерфейса
2. непонятно использует ли СУБД
3. использование tcl мне не шибко нравится хотя это уже IMHO
4. а где мониторинг ?
| | |
|
| |
| |
| 3.40, Belal (??), 19:30, 09/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
 Могу предложить другое решение - OpenNMS.
WEB-интерфейс. Мониторинг доступности сервисов (HTTP,SMTP,POP3,DNS) и хостов(по ICMP). Сбор статистики по SNMP (от UPS-ки до Cisco-маршрутизаторов ). Хранение статистики и отрисовка графиков c использованием rrd-tools(развитие пакета MRTG).
Настройка нотификаций с єкскалацией по SNMP-trap событию и по исчезновению сервиса/хоста.
Гибкие настройки в XML.
Ведение инветарной базы оборудовния.
Кофе не варит:)
| | |
| |
| 4.41, sauron (ok), 08:27, 10/06/2005 [^] [^^] [^^^] [ответить]
| +/– |
>Могу предложить другое решение - OpenNMS.
>WEB-интерфейс. Мониторинг доступности сервисов (HTTP,SMTP,POP3,DNS) и хостов(по ICMP). Сбор статистики по
>SNMP (от UPS-ки до Cisco-маршрутизаторов ). Хранение статистики и отрисовка графиков
>c использованием rrd-tools(развитие пакета MRTG).
>Настройка нотификаций с єкскалацией по SNMP-trap событию и по исчезновению сервиса/хоста.
>
>Гибкие настройки в XML.
>Ведение инветарной базы оборудовния.
пробовал жрет много ресурсов и заточено только под tomcat
| | |
|
|
|
|
