>Вы какой-то непонятливый. По-моему это очевидно, что цифра нужна для оценки производительности. Вы странно меряете производительность. 50 мегов каждые 15 секунд сбрасывать по новой не напряжно. А 83 INSERT делать напряжно.
>Еще как поспорю :-)
>Zabbix использует, как INSERT, так и UPDATE.
>Если меняется состояние, то это INSERT+UPDATE, а если не меняется то INSERT.
Еще раз для не понятливых. INSERT производится при добавлении данных. UPDATE состояний производится только при их ИЗМЕНЕНИИ. состояния отделены от данных и по этому их можно и нужно обновлять только при их изменении. Перестаньте думать что zabbix это копия nagios только с СУБД.
>У Nagios свои понятия :-)
>В Nagios плагины, кроме состояния отдают на стандартный вывод и детальную информацию
>о результатах прошедшей проверки. Чем вам это не данные?
Тем что на их основе не строятся состояния. Эти данные являются побочными. К тому же в отличии от zabbix где к данным имеется прямой доступ (согласно используемой модели) эти данные сначала парсятся внутри nagios часто perl плагином. Хотите сказать это не сказывается на производительности?
>Я имел в виду, что после каждой проверки неизбежно следуют обращения к
>БД, что бы занести "данные" и возможно обновить состояние объекта, если
>это следует из выражений.
Не правильно. После каждой проверки не имеет смысла заносить данные в СУБД. Там уже "такие данные". Zabbix работает от данных а не от состояниий. Именно по этому не имеет смысла их обновлять.
>Та нагрузка, которую создает само ядро мониторинга (процесс nagios) - пустяк даже
>при очень большом кол-ве объектов. Нагрузку делают плагины, когда при очень
>тесном расписании их может запускаться параллельно несколько штук. А у zabbix
>не только процесс создает нагрузку на CPU, но и его СУБД тоже.
По сравнению с запуском пачки плагинов на перле и последующим разбором их данных это полная фигня. Запуск + работа + останов процесса всегда жрут больше ресурсов чем работа одного процесса.
>ОК, после каждой проверки обязательно минимум один INSERT и в случае изменения
>состояния минимум один UPDATE - согласны?
Проверки чего? INSERT выполняется при запросе и получении данных. К примеру мы запрашиваем по SNMP количество байт прошедших через интерфейс. А UPDATE возникает только если значение выражения которое использует этот параметер изменилось.
>83 - это я вас пожалел просто, взял по минимуму :)
>В реальных условиях это число будет в разы больше.
Не сказал бы.
>Я не спорю, что Perl медленней программ на Си.
>Сборка с embedded-perl позволяет существенно повысить производительность за счет включения инерпретатора внутрь
>самого демона мониторинга. Можно и совсем отказаться от Perl, Shell, PHP
>плагинов - это уж дело админское.
Но при этом у вас все равно остаются затраты на запуск и останов процессов.
>Вы мне конкретный приведите пример чего-то такого.
>В Nagios у меня строятся отчеты самые разные, выборка данных на лицо.
Хорошо покажите мне данные за конкретный период времени и постройте по нему график к примеру 3 часовой график события что было 2 дня назад в 18 часов.
>Пожалуйста приведите пример, так сказать проиллюстрируйте, каким образом выражения Zabbix >являются гибче плагинов.
Элементарно. Мне надо мониторить 4 порта на каталисте. Когда общий поток превышает 10мбит в течении 6 минут то отправить уведомление.
>Я вот с Nagios точно знаю, что мне под силу любая проверка. Я всегда могу взять и написать свой плагин.
См. выше. Сколько времени вы будете писать плагин? Я выражение минуты за 3 напишу. Это если брать по максимуму.
>То же касается методов уведомления, захотел я в аську получать алерты -
>пожалуйста. А в zabbix что ли вообще нет плагинов?
У меня в jabber присылает. На раз.
>Все данные Nagios пишет в журналы, status.dat содержит базу текущих состояний каждого
>хоста/сервиса и детальную инфу о данном состоянии. Что для вас данные?
Для меня данные это состояние 24 портов каталиста к примеру. Туда входит не только поднят ли интерфейс но и сколько данных через них проходит, загрузка CPU на нем.
>50Мб на 45000 объектов - это _очень_ немного :-)
>Тем более status.dat можно в RAM-диске держать и вообще глазом моргнуть не
>успеете, как файл пропарсится на раз.
Ага а в случае сбоя мы рискуем потерять данные.
>Кстати 45000 объектов - это реальность для Nagios, а вот есть ли
>данные о том, что кто-то живет в zabbix с таким же
>количеством?
2000 узлов точно есть. Но в вашем случае надо мерять по items. на каждый узел было точно по 10 параметров. Т.е. 20000 items.
>Я ж не сказал, что данные старше месяца удаляются. Ротация логов -
>это значит, что просто создается новый файл каждуый день,неделю или месяц
>(как пожелает админ). В последствии Nagios очень быстро по названию файлов
>найдет нужные для построения отчета и будет парсить только эти файлы.
>И в Nagios данные вообще никогда не удаляются, даже после года.
Вам не кажется что для системы мониторинга это костыли? Мне вот кажется.
>Необходимость эта не является минусом, ведь т.к. данная операция не тратит процессорного
>времени и происходит мгновенно даже при очень большом числе объектов.
Мгновенно сбрасывается 50 мегабайт ? Вау! Гречка!
>Расскажите подробней про статистику.
Зайдите на сайт и ознакомтесь что умеет делать из коробки zabbix.
>Уже ответил выше по поводу UPDATEов/INSERTов.
И абсолютно не верно ответили.
>С разными, а чем вы хотите возразить?
Да. С понятием транзакция знакомы? Да и объясните мне почему update у вас является такой трудоемкой операцией?
>Время покажет :-)
Как не странно, но те коллеги которые использовали nagios после подробного озакомления с zabbix переходили на него. И говорили что он удобнее.
>На сколько я понимаю, выражения - это средство построения решающего правила для
>перевода объектов из одного состояния в другое. Какими бы хорошими не
>были выражения они не смогут реализовать сложный алгоритм.
Если вам нужен сложный алгоритм никто не мешает расширить zabbix через скрипты аля nagios.
>C Event Broker я могу встроиться в самое сердце Nagios и не
>только обрабатывать но и порождать события.
Породить событие я могу и через trapper в zabbix. Порождать события требуется только потому что в nagios событийная модель и она обрабатывает события. В zabbix идет обработка данных в связи с чем это особо и не требуется.
>Конечно в повседневной практике это редко кому-то может понадобиться, но если речь заходит о чем-то ну очень экзотичном и нестандартном, то с Nagios можно чуствовать себя, имхо, более свободно.
Nagios как система проще и понятнее. Но она менее гибка. Т.к. zabbix можно расширить так же как и nagios.
>Любую в смысле решения любой задачи по мониторингу.
Попробуйте а я посмотрю. Я уверен что вы не сможете построить аналог. Системы слишком разные.
>Через перехват проверок можно их результаты заносить в СУБД и дальше делать
>с ними, что угодно (не забывайте что плагины еще имеют инфу
>на стандартном выводе, что, как полагаю, соответствует слову "данные").
Не соответсвуют. Я уже про это много раз говорил.
>Из нашей с вами дискуссии я почерпнул, что выражения - это большое достоинство
>zabbix. Будет неплохо, если вы расскажите как эти выражения реально используются
>и какие задачи реально ими решаются.
Выражения используются для задания триггеров генераторов событий. Пример использования я уже привел выше.
