| 1.1, моррут (?), 16:28, 13/06/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
управляется виндовской программой
есть веб интерфейс - но не собирается | | |
| |
| 2.2, sauros (?), 16:45, 13/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
 А какие ошибки при сборке веб-интерфейса?
Кстати, консоль работает также и под Wine (не самый хороший вариант конечно...)
| | |
| |
| 3.53, sfd (?), 23:47, 24/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>А какие ошибки при сборке веб-интерфейса?
>
>Кстати, консоль работает также и под Wine (не самый хороший вариант конечно...)
>
да кстати, как только узнал что нет нативной консоли для линукса - сразу подпортило впечатление
| | |
|
|
| |
| 2.6, sauron (??), 21:10, 13/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >кто нибудь может сравнить сабж с zabbix, nagios?
По архитектуре и методикам обработки ближе к zabbix. Из минусов без виндовой консоли не конфигурабелен. | | |
| |
| 3.11, Alex Kirhenshtein (?), 01:11, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
 > По архитектуре и методикам обработки ближе к zabbix.
Не совсем. Заббикс завязан на базу, и в этом их очень большая проблема. Забрали значение с агента, insert в базу. Пришел юзер на веб - select соорудили. Из этого вытекают проблемы вида "удаляем ноду из базы вместе с историей, скажем, при этом ничего не собирается - база полочила таблицы, insert-ы не проходят, пока всё не удалится" (это пример из их рассылки, в качестве решения предложено сменить базу на более шуструю). Из этой же прямой работы с базой вытекают огромные проблемы с stand-alone клиентом (и конкурентными пользователями системы).
У нас, в свою очередь, всё хранится в памяти, и синхронизируется с базой отдельными потоками. При этом могут одновременно работать несколько администраторов, каждый со своими группами серверов, скажем. Плюс, такая архитектура позволяет делать удобные штуки типа подписки на события - т.е. скажем малентькому тулу из трея, который показывает тревоги, не надо постоянно pool-ить сервер, ему достаточно подписаться на получение новых тревог.
Замечательно работает на GPRS-е, скажем.
Да, про перфоманс и требования к памяти: один из наших клиентов, у которых сейчас больше 300-т нод, сервер гоняет на старом p3/700 с 512 памяти под FreeBSD, база бежит на той же машине. В рассылке у нас есть человек из норвежского ISP, который пробовал мониторить рутера с количеством интерфейсов больше трёх тысяч. Не знаю, впрочем, про железо, на котором это всё бегало - но бегало, и хорошо. | | |
| |
| 4.15, sauron (??), 09:18, 14/06/2007 [^] [^^] [^^^] [ответить] | +/– | Совсем Я говорю о методиках обработки и генерации событий А не про то как хр... большой текст свёрнут, показать | | |
| |
| 5.22, Victor Kirhenshtein (?), 12:22, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>>Не совсем.
>Совсем :) Я говорю о методиках обработки и генерации событий. А не
>про то как хранятся данные.
Не совсем :) У нас центром является обработка событий, а в 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 сервер - это такой-же клиент, как и консоль. Т.е. их может быть много, разных, на разных машинах.
| | |
| |
| 6.23, sauron (??), 14:14, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Не совсем :) У нас центром является обработка событий, а в 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 сервер - это такой-же клиент, как и консоль. Т.е. их может
>быть много, разных, на разных машинах.
Конечно. Только вот где у вас унифицированный интерфейс взаимодействия клиента с сервером? | | |
| |
| 7.25, Victor Kirhenshtein (?), 15:46, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Так события на основе чего генерятся? Может на основе определенного значения у
>узла? Если нет и события могут быть порождены только какими либо
>внешними событиями типа 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.
| | |
| |
| 8.31, sauron (??), 18:52, 14/06/2007 [^] [^^] [^^^] [ответить] | +/– | В zabbix триггеры умеют существенно больше Так как они из себя представляют выч... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| |
| 2.5, sauron (??), 21:09, 13/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>А почему интересно графики не в rrdtool рисуются, а своим кодом?
Потому что использование рисования графиком rrdtool показатель пионерии. Так как rrdtool не умеет нативно рисовать графики из СУБД. И работать с данными в формате баз rrdtool не особо удобно, особенно когда таких данных много. | | |
| |
| 3.26, citrin (??), 16:02, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
 Я сильно сомневаюсь, что на больших объемах данных SQL будет быстрее чем RRD.
База фиксированного размера (в rrd) должна работать быстрее чем универсальный сторадж SQL который ничего не знает о том, что данные нужно хранить фиксированного объема (не собираетесь же вы вечно хранить данные с 5-и минутным интервалом). SQL ничего не знает и про то что часть запросов никогда не понадобится (и поэтому его схема хранения не будет оптимальной для данной задачи).
SQL это универсально, но в тех случаях когда есть узко специализированные базы (типа RRD) работают они как правило лучше. | | |
| |
| 4.30, sauron (??), 18:44, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Я сильно сомневаюсь, что на больших объемах данных SQL будет быстрее чем
>RRD.
Медленнее.
>База фиксированного размера (в rrd) должна работать быстрее чем универсальный сторадж SQL
>который ничего не знает о том, что данные нужно хранить фиксированного
>объема (не собираетесь же вы вечно хранить данные с 5-и минутным
>интервалом). SQL ничего не знает и про то что часть запросов
>никогда не понадобится (и поэтому его схема хранения не будет оптимальной
>для данной задачи).
Вот как раз будет. В отличии от rrd я могу посмотреть любой удобный интервал. Главное бы данные были. В rrd этого нет.
>SQL это универсально, но в тех случаях когда есть узко специализированные базы
>(типа RRD) работают они как правило лучше.
Если мне надо посмотреть график за 5 минут за 12 часов за сутки за месяц то да. Но если надо несколько гибче да еще надо что-то кроме графиков, то rrd пролетает как фанера над парижем. | | |
| |
| 5.33, _Nick_ (??), 19:21, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >>База фиксированного размера (в rrd) должна работать быстрее чем универсальный сторадж SQL
>>который ничего не знает о том, что данные нужно хранить фиксированного
>>объема (не собираетесь же вы вечно хранить данные с 5-и минутным
>>интервалом). SQL ничего не знает и про то что часть запросов
>>никогда не понадобится (и поэтому его схема хранения не будет оптимальной
>>для данной задачи).
>Вот как раз будет. В отличии от rrd я могу посмотреть любой
>удобный интервал. Главное бы данные были. В rrd этого нет.
RRD база - это константное количество значений на временной оси, расположенных с заданным интервалом.
Вопрос: КАКИМ нужно местом думать чтоб не суметь запросить множество значений
за необходимый интервал?
>>SQL это универсально, но в тех случаях когда есть узко специализированные базы
>>(типа RRD) работают они как правило лучше.
>Если мне надо посмотреть график за 5 минут за 12 часов за
>сутки за месяц то да. Но если надо несколько гибче да
>еще надо что-то кроме графиков, то rrd пролетает как фанера над
>парижем.
Тебе же написали: RRD - быстрее, но задача у нее УЖЕ по сравнию с SQL.
Что ты продолжаешь мерять свой узорчатый но медленный? | | |
| |
| 6.35, sauron (??), 19:58, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Вопрос: КАКИМ нужно местом думать чтоб не суметь запросить множество значений
>за необходимый интервал?
А это тут причем? В случае с SQL я могу легко и не принужденно ничего не изменяя увеличивать и уменьшать этот интервал. У rrd это так легко не получится. Тоже самое могу сказать и про копирование или пересчет данных. Хранение данных в СУБД дает больше возможностей. rrd же позволяет выбирать линейные отрезки. В своей узкой области оно удобно, но не более.
>Что ты продолжаешь мерять свой узорчатый но медленный?
Я ничего не меряю. Я высказываю свое мнение. И мое мнение таково что использовать в более-меннее серьезных системах мониторинга rrd не стоит.
| | |
| |
| 7.37, _Nick_ (??), 20:34, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>>Вопрос: КАКИМ нужно местом думать чтоб не суметь запросить множество значений
>>за необходимый интервал?
>А это тут причем? В случае с SQL я могу легко и
>не принужденно ничего не изменяя увеличивать и уменьшать этот интервал. У
>rrd это так легко не получится.
На самом деле в RRD храниться массив: UNIX время - значение.
Т.е. интеревала как такового нет. Он задаеться только скоростью добавления данных в базу.
>Тоже самое могу сказать и
>про копирование или пересчет данных. Хранение данных в СУБД дает больше
>возможностей. rrd же позволяет выбирать линейные отрезки. В своей узкой области
>оно удобно, но не более.
Ты различаешь быстрее и удобнее? Так вот RRD БЫСТРЕЕ на определенных операциях.
Про гибкость SQL'я мы тут уже все наслышаны..
>>Что ты продолжаешь мерять свой узорчатый но медленный?
>Я ничего не меряю. Я высказываю свое мнение. И мое мнение таково
>что использовать в более-меннее серьезных системах мониторинга rrd не стоит.
Ты спутал SQL с RRD и высказываешься, что без SQL ничего серьезного не бывает.
ДА. Так оно и есть. Но кто сказал, что данные нужно собирать сразу в какой-нить мускуль?
Сбор - это рутина и она должна быть быстра. И только нужна более детальная обработка (да, да, все те сложные запросы с пачкой условий, сриптофф-на-перле и т.д.) - вот тут забирай данные из RRD базы в хранилище на SQL и рули куда нужно. | | |
|
|
| 5.49, etz (??), 14:50, 26/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >Вот как раз будет. В отличии от rrd я могу посмотреть любой
>удобный интервал. Главное бы данные были. В rrd этого нет.
Есть. при заполнении базы можно её бэкапить. на джаваскрипте легко пишется обрамление к графику позволяющиее перейти на любой интервал, увеличить/уменьшить масштаб
>>SQL это универсально, но в тех случаях когда есть узко специализированные базы
>>(типа RRD) работают они как правило лучше.
>Если мне надо посмотреть график за 5 минут за 12 часов за
>сутки за месяц то да.
*за любой промежуток присутвующий в базе. *быстро
>Но если надо несколько гибче да
>еще надо что-то кроме графиков, то rrd пролетает как фанера над
>парижем.
rrd предназначена для аккумулирования данных и постройки графиков любой конфигурации на основании этих данных
Ну а вообще, конечно, молоток это пионерия.. и лучше использовать микроскоп для забивания гвоздей.. | | |
| |
| 6.50, sauron (??), 14:55, 03/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Есть. при заполнении базы можно её бэкапить. на джаваскрипте легко пишется обрамление
>к графику позволяющиее перейти на любой интервал, увеличить/уменьшить масштаб
Можно. Но не является нативным средством. К тому же мне интересно как вы будете показывать данные половина которых в одной базе, а вторая в другой.
>*за любой промежуток присутвующий в базе. *быстро
Ключевой момент присутсвующий в базе. Потом есть еще одна проблема это то что у rrd нет механизмов разруливания записи несколькими клиентами.
>rrd предназначена для аккумулирования данных и постройки графиков любой конфигурации на >основании этих данных
Я в курсе зачем оно необходимо. Но дело в том что тот же zabbix использует эти данные не только для посторения графиков, но еще и для генерации тревог, на базе вычисляемого значания по интервалу.
>Ну а вообще, конечно, молоток это пионерия.. и лучше использовать микроскоп для
>забивания гвоздей..
Инстументы надо по назначению использовать. rrd он неплох когда вам требуются только графики. Но как только вам потребуются не только графики наступает оппаньки. | | |
|
|
|
|
|
| 1.7, vbv (ok), 21:28, 13/06/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Мне нужна система мониторинга.
Но ради этого ставить M$ или wine - мрачно....
Пока сам рисую и дописываю части.
Если уж и писать - то писать надо под что-то одно, человеческое.
Много самому дописывать - долго и не удобно.
Да система мониторинга - хорошо.
Но пока не появиться человеческого продукта полностью под Linux не буду даже пробовать ставить.
Мне зоопарка и так хватает. | | |
| |
| |
| 3.16, sauron (??), 09:20, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>А вот что вам интереснее - нативная консоль под Линукс, или полноценный
>веб-интерфейс?
Интереснее был бы вебинтерфейс. Если вам хочется сохранить модель работы аналогичную с windows-консолью, то посмотрите такие вещи как XML-RPC или SOAP. | | |
|
| 2.9, nobody (??), 00:18, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– | |
www.nagios.org. нормальная система мониторинга промышленного уровня. Все сказанное про NetXMS делает с успехом, а то и больше. | | |
| |
| 3.10, Alex Kirhenshtein (?), 00:49, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Есть один минус у нагиоса - конфигурация.
Тут всё заточено под то, чтоб всё можно было настраивать и управлять из одной точки - администраторской консоли. Просмотр логов, графики, правка конфигов агентов, их апгрейд, etc.
К примеру, апгрейд агентов выглядит так:
через консоль администратора заливаете на сервер новый пекедж (может быть в разных формах - исходники, готовые бинарники), после чего выбираете ноду(контейнер, всю сеть, etc) - и указываете, какой пекедж надо туда поставить. Всё делается из одной точки. Причем, агент для win32/x86 не будет наложен на Solaris, скажем.
С конфигами - аналогично, правый клик на ноде, "edit agent config" - и редактируем. Закончили - агент автоматом перезапустится.
Никаких "ssh на хост1, потом ssh на хост2, потом делаем скриптик".
Или, скажем, агенты могут запрашивать конфиг у сервера - при старте. А сервер умеет отдавать нужный в зависимости от условий - будь то архитектура системы, версия агента, или hostname ноды.
Я не спорю, что это всё решается скриптами, но мы пытаемся сделать комплексное решение - чтоб не приходилось каждый раз писать мелкие "костыли" | | |
| |
| 4.12, HASP (?), 04:06, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
очень и очень интересно...
три года пользуем нагиос, немалый уже есть опыт, но конфигурирование его это конечно песня еще та.. дак вот вопрос по теме - работает ли все таки WEB в этой штуке? в документации очень мало по этому поводу, а у нас дисперчера уже привыкли | | |
| |
| |
| 6.20, _Nick_ (??), 11:19, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– | |
налицо ошибочная стратегия пользовательского интерфейса.
в век WEB-2.0 и начала конца венды делать ставку на маздаюную админку...
как минимум было неразумно....
ессьно, сейчас спохватились, но _что_ будет и _как_ сделано в этой спешке - это вопрос еще тот... | | |
| |
| 7.21, Victor Kirhenshtein (?), 12:11, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
Одна из основных идей системы - модульность. Так, web интерфейс - это такой-же клиент, как и консоль, и использует он одну и ту-же клиентскую библиотеку (и располагатся кстати может на другой физической машине). Такой подход позволяет иметь неограниченное количество UI - можно сделать и консоль под X, и альтернативный web UI, и интеграцию с другими системами. С Windows консоли рачали только потому, что мне web интерфейсы не нравятся, а система во многом написана под себя и некоторых клиентов моей компании. Основная проблема - девелоперов только двое, и многие вещи не успеваем делать так быстро, как хотелось бы. Ну и суйчас я думаю, что было бы правильней консоль делать под wxWidgets - тогда бы ее легко можно было бы перенести на Linux. Мы этот вариант (переписать под wxWidgets) сейчас обдумываем - но в любом случае быстро это не будет.
| | |
|
|
|
| 4.44, tigrisha (??), 10:39, 15/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Есть один минус у нагиоса - конфигурация.
Возьмите к примеру вот это http://www.groundworkopensource.com/ и никаких проблем с конфигурацией не будет
>К примеру, апгрейд агентов выглядит так:
>через консоль администратора заливаете на сервер новый пекедж (может быть в разных
>формах - исходники, готовые бинарники), после чего выбираете ноду(контейнер, всю сеть,
>etc) - и указываете, какой пекедж надо туда поставить. Всё делается
>из одной точки. Причем, агент для win32/x86 не будет наложен на
>Solaris, скажем.
А вот это вообще не должно входит в обязанности системы мониторинга. Посмотри в стандарты ITSM или MOF там четко описан процесс Configuration Management. Соответственно на предприятии предпочтительно иметь одну систему управления ПО и конфигураций а не ворох от каждого производителя. | | |
|
| 3.17, sauron (??), 09:24, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>www.nagios.org. нормальная система мониторинга промышленного уровня. Все сказанное про NetXMS делает с
>успехом, а то и больше.
Эта штука нифига не промышленного уровня. К тому же nagios это просто система регистрации событий и не более того. | | |
| |
| 4.29, nobody (??), 18:28, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>>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.
есть еще много фич невидных сначала. | | |
| |
| 5.32, sauron (??), 19:07, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>http://www.nagios.org/userprofiles/search.php?search=1. неполный список организаций ислоьзующих нагиос.
>нагиос не только регистрации событий. у него есть такое понятие как event
>handler,
Для тех кто в танке поясняю. Оно не УМЕЕТ само высчитыавать на показании каких либо данных генерировать какие либо тревоги. Оно умеет только регистировать события от плагинов. В связи с чем использование nagios в среде где у вас много устройств с SNMP превращается в pain in ass. К тому же отказ от использования СУБД положительно на масштабируемости не сказывается. | | |
| |
| 6.34, _Nick_ (??), 19:48, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Для тех кто в танке поясняю. Оно не УМЕЕТ само высчитыавать на
>показании каких либо данных генерировать какие либо тревоги. Оно умеет только
>регистировать события от плагинов. В связи с чем использование nagios в
>среде где у вас много устройств с SNMP превращается в pain
>in ass.
Хоть я и не сторонник нагиоса, но если у нас мало устройств с SNMP? ;)
>К тому же отказ от использования СУБД положительно на масштабируемости не сказывается.
все за свое.....
для тебя СУБД - это именно SQL? :)
открою тебе глаза: у нагиоса есть свой метод хранения полученных данных.
Хранением нужно управлять и он это делает. Кто сказал, что в нагиосе нет СУБД? :)
Ну а если ты все же про SQL - то я уже писал что универсальность обратнопропорциональна скорости.
О проблемах некой универсальной СУБД (аля мускуль, постгрес) тут уже кто-то писал, что локи на таблицы делают такое решение плохо масштабируемым или попросту говоря тормознутым (почти как Giant Lock во бзде ;). | | |
| |
| 7.36, sauron (??), 20:07, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Хоть я и не сторонник нагиоса, но если у нас мало устройств
>с SNMP? ;)
Если у вас их мало и вас устраивают все плагины нагиоса юзайте.
>для тебя СУБД - это именно SQL? :)
Для меня СУБД это система управления базами данных. И они как-то чаще всего бывают реляционными.
>открою тебе глаза: у нагиоса есть свой метод хранения полученных данных.
А мужики то не знают! И что оно там хранит и как? Нативно оно само умеет писать только журнал событий и не более. Все графики приделываются сторонними средствами и хранят данные в отдельных rrd базах.
>Хранением нужно управлять и он это делает. Кто сказал, что в нагиосе
>нет СУБД? :)
А что у нас журнал событий уже стал СУБД?
>Ну а если ты все же про SQL - то я
>уже писал что универсальность обратнопропорциональна скорости.
То-то все реляционные СУБД используют.
>О проблемах некой универсальной СУБД (аля мускуль, постгрес) тут уже кто-то писал,
>что локи на таблицы делают такое решение плохо масштабируемым или попросту
>говоря тормознутым (почти как Giant Lock во бзде ;).
Читайте выше. Локи на таблицы есть только в MySQL при использовании движка MyISAM. В случае использования InnoDB этого НЕ ПРОИСХОДИТ. Во всех других СУБД более серьезных СУБД этого нет уже очень давно. Транзакции рулят. К тому же у меня сейчас используется zabbix с СУБД mysql база весит 23 гига. Работает все хорошо и быстро. Что я не так делаю? | | |
| |
| 8.38, _Nick_ (??), 21:24, 14/06/2007 [^] [^^] [^^^] [ответить] | +/– | Труъ Для меня тоже, как ни странно Внимательно читаем определение СУБД можн... большой текст свёрнут, показать | | |
| |
| 9.42, sauron (??), 07:55, 15/06/2007 [^] [^^] [^^^] [ответить] | +/– | А мужики то не знают В том виде что она есть сейчас она меня мало устраивает ... текст свёрнут, показать | | |
|
|
|
| 6.45, tigrisha (??), 11:06, 15/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>>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.
| | |
|
| 5.47, tigrisha (??), 16:29, 15/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>>Эта штука нифига не промышленного уровня. К тому же nagios это просто
>>система регистрации событий и не более того.
>
>http://www.nagios.org/userprofiles/search.php?search=1. неполный список организаций ислоьзующих нагиос.
Ну это вообще ни разу не доказательство качества программы. 300 миллионов лемингов не могут ошибаться! Nagios так же использует AOL или Связьинвест. И что с того?
На рынке побеждает не тот кто лучше продукт выпускает, а тот кто пришел первым и у кого маркетинг лучше!!
Стоит отметить что лет 5 назад Nagios был системой очень даже хорошего уровня. Но ничто под луной не вечно.
Посмотрите на досуге Zenoss, OpenNMS | | |
|
|
|
|
| 1.14, sergey (??), 08:12, 14/06/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Я думаю что интересно как Web-интерфейс (хотя бы возможность отчётов и сигнализации проблем) так и нативная консоль под Линукс. | | |
| 1.18, Vladimir (??), 10:32, 14/06/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Кстати, кто нибудь может подсказать софт, который мониторит аппаратные конфигурации? К сожалению под *nix я таких не видел, либо плохо искал. Zabbix и Nagios мониторят только состояния, эта система тоже. Очень сильно не хватает собирать централизовано информацию о конфигурациях компьютеров.
| | |
| |
| 2.19, Evgeni (??), 11:10, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Кстати, кто нибудь может подсказать софт, который мониторит аппаратные конфигурации? К сожалению
>под *nix я таких не видел, либо плохо искал. Zabbix и
>Nagios мониторят только состояния, эта система тоже. Очень сильно не хватает
>собирать централизовано информацию о конфигурациях компьютеров.
OCSInventory попробуй. | | |
| |
| 3.24, edgars (??), 15:15, 14/06/2007 [^] [^^] [^^^] [ответить]
| +/– |
>>Кстати, кто нибудь может подсказать софт, который мониторит аппаратные конфигурации? К сожалению
>>под *nix я таких не видел, либо плохо искал. Zabbix и
>>Nagios мониторят только состояния, эта система тоже. Очень сильно не хватает
>>собирать централизовано информацию о конфигурациях компьютеров.
>
>
>OCSInventory попробуй.
mozhet RANCID?
| | |
| |
| 4.52, user234 (?), 17:39, 15/01/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>>Кстати, кто нибудь может подсказать софт, который мониторит аппаратные конфигурации? К сожалению
>>>под *nix я таких не видел, либо плохо искал. Zabbix и
>>>Nagios мониторят только состояния, эта система тоже. Очень сильно не хватает
>>>собирать централизовано информацию о конфигурациях компьютеров.
>>
>>
>>OCSInventory попробуй.
>
>mozhet RANCID?
У Zabbix с этим большие проблемы. Планируется ли как-то усовершенствовать работу с trap-ами?
| | |
|
|
|
|
