>>Не надо рассматривать каждый тезис, как покушение на zabbix или СУБД.
>>Просто когда мы имеем конкретную цифру, то можно более предметно рассуждать о
>>производительности.
>Я просто не понял зачем приведена эта цифра. Объем аналогичных данных что
>в zabbix, что в nagios будет сравним. Так что смысла приводить
>эту цифру я не вижу. Вы какой-то непонятливый. По-моему это очевидно, что цифра нужна для оценки производительности.
>>И получается, что после каждой проверки zabbix шлет миниммум один UPDATE в
>>СУБД, а Nagios не зависимо от кол-ва совершившихся проверок каждые 15
>>сек. (или сколько скажете) обновляет status.dat.
>Не верно. Zabbix производит вставку данных в СУБД т.е. использует INSERT. В
>результате можно всегда проанализировать какие значения были при сбое. Плюс можно
>пранализировать какие значения были перед сбоем. Nagios такие данные считает побочными
>и по умолчанию их не сохраняет. Если же их начать сохранять
>у Nagios начинает падать производительность. Надеюсь с этим спорить не будете
>?
Еще как поспорю :-)
Zabbix использует, как INSERT, так и UPDATE.
Если меняется состояние, то это INSERT+UPDATE, а если не меняется то INSERT.
>>Будьте внимательны, я ведь так и написал: "каждый раз, если меняется состояние
>>объекта"...
>Состояние объекта меняется только когда оно меняется. В nagios нет понятия данных
>именно по этому состояние объекта необходимо обновлять.
У Nagios свои понятия :-)
В Nagios плагины, кроме состояния отдают на стандартный вывод и детальную информацию о результатах прошедшей проверки. Чем вам это не данные?
>>На деле zabbix должен обновлять данные в БД после каждой проверки, даже
>>если само состояние объекта осталось прежним (см. выше).
>Не обновляет. Так как он работает с данными и СУБД, а не
>с тревогами как Nagios.
Я имел в виду, что после каждой проверки неизбежно следуют обращения к БД, что бы занести "данные" и возможно обновить состояние объекта, если это следует из выражений.
>>У нас Nagios, который не использует СУБД и сам по себе не
>>грузит процессор
>Ага nagios у нас ничего не делает и процессор не грузит вообще.
>Вы не считаете что это из области сказок.
Та нагрузка, которую создает само ядро мониторинга (процесс nagios) - пустяк даже при очень большом кол-ве объектов. Нагрузку делают плагины, когда при очень тесном расписании их может запускаться параллельно несколько штук. А у zabbix не только процесс создает нагрузку на CPU, но и его СУБД тоже.
>>а zabbix неизбежно делает UPDATEы после каждой проверки.
>Вы сначала бы в код zabbix'а глянули прежде чем такие заявления делать.
ОК, после каждой проверки обязательно минимум один INSERT и в случае изменения состояния минимум один UPDATE - согласны?
>>Представим, что у нас есть 5000 хостов и у каждого хоста есть
>>сервис, который должен проверяться ежеминутно. Получается, что каждую минуту делается >5000 проверок, что составляет ~83 проверки в секунду. В случае СУБД ориентированного
>>подхода это выливается в минимум 83 UPDATEа в секунду нагрузки на
>>СУБД. По-моему это может заставить систему призадуматься :-)
>83 не UPDATE а INSERT это не особо большая нагрузка для СУБД.
83 - это я вас пожалел просто, взял по минимуму :)
В реальных условиях это число будет в разы больше.
>>Расходы на запуск бинарного файла не велики
>с точки зрения ОС очень даже велики.
>>а что касается плагинов на Perl, то можно собрать Nagios с ключиком --enable-embedded-perl.
>Ну как вам сказать. Есть такая штука Spamassasin она написана на perl.
>Так вот под нагрузкой он начинает жрать очень много памяти и
>дико грузить машину. Причем аналогичное решение C clapf этого не делает
>и памяти ест мало. При небольших нагрузках использовать perl можно но
>при больших лучше не стоит. Не та модель у него.
Я не спорю, что Perl медленней программ на Си.
Сборка с embedded-perl позволяет существенно повысить производительность за счет включения инерпретатора внутрь самого демона мониторинга. Можно и совсем отказаться от Perl, Shell, PHP плагинов - это уж дело админское.
>>По-моему мои доводы обоснованы и объективны, я привел простые расчеты и ни
>>в одном месте не дал повод думать будто для меня СУБД - это интерфейс работы с файлом.
>К сожалению дали. Т.к. вы работате с СУБД как с файлом. Вы
>например не пользуютесь возможностями поиска и выборки данных.
Вы мне конкретный приведите пример чего-то такого.
В Nagios у меня строятся отчеты самые разные, выборка данных на лицо.
>>Модель объектов мониторинга и аттрибутов действует для любого подхода.
>Модель чего? Давайте проведем небольшую такую черту. И так. Nagios непосредственно с
>данными не работает он работает с состояниями объектов. Zabbix работает с
>данными, а уже на их основе строит состояния объектов. Что позволяет
>быть zabbix более гибкой системой чем Nagios. В nagios данная вещь
>существует только побочно.
Пожалуйста приведите пример, так сказать проиллюстрируйте, каким образом выражения Zabbix являются гибче плагинов. Я вот с Nagios точно знаю, что мне под силу любюая проверка. Я всегда могу взять и написать свой плагин. То же касается методов уведомления, захотел я в аську получать алерты - пожалуйста. А в zabbix что ли вообще нет плагинов?
>>Дампу объектов в status.dat будет достаточно обычного IDE винта и при четверти
>>миллиона объектов (расчеты я приводил) :-)))
>Мне нужны не только статусы мне еще нужны данные.
Все данные Nagios пишет в журналы, status.dat содержит базу текущих состояний каждого хоста/сервиса и детальную инфу о данном состоянии. Что для вас данные?
>>Для того, что бы отобразить список хостов и/или сервисов Nagios должен открыть
>>для чтения и пропарсить status.dat размером 50 Мб (если мы говорим
>>о 45000 объектах).
>Эээ вы сами поняли что сказали? 50 мегабайт это довольно много. Хорошо
>конечно если ОС его закеширует и операции будут выполнятся быстрее. Но
>операция выборки не всех объектов а конкретной группы объектов будет занимать
>практически одно и тоже время при использовании файла. При использовании СУБД
>и частом обращении время будет уменьшаться.
50Мб на 45000 объектов - это _очень_ немного :-)
Тем более status.dat можно в RAM-диске держать и вообще глазом моргнуть не успеете, как файл пропарсится на раз.
Кстати 45000 объектов - это реальность для Nagios, а вот есть ли данные о том, что кто-то живет в zabbix с таким же количеством?
>>Бинарный cgi скрипт легко с этим справится, долго ждать не придется. Тот факт, что >несколько юзеров одновременно запросят данную операцию тоже проблем не вызовет.
>попробуйте 10-20 пользователями.
>>Nagios обеспечивает по выбору суточную, недельную
>>или ежемесячную ротацию журналов - это дает возможность ускорить обработку и
>>выдачу результатов по отчетам за короткий промежуток времени (именно такого типа
>>отчеты чаще всего используются).
>Хехе. В zabbix по умолчанию хранится полная история за три месяца. Данные
>более чем за три месяца агрегируются и хранятся в течении года.
Не радуйтесь :-)))
Я ж не сказал, что данные старше месяца удаляются. Ротация логов - это значит, что просто создается новый файл каждуый день,неделю или месяц (как пожелает админ). В последствии Nagios очень быстро по названию файлов найдет нужные для построения отчета и будет парсить только эти файлы. И в Nagios данные вообще никогда не удаляются, даже после года.
>>Словом по-моему нет никаких мегаминусов связаных с тем, что nagios не использует СУБД.
>Мегаминусом Nagios является жесткая система плагинов и обработка только состояний, а не
>данных. Небольшим минусом является необходимось сохранять данные каждые 15 секунд на
>винчестер.
Необходимость эта не является минусом, ведь т.к. данная операция не тратит процессорного времени и происходит мгновенно даже при очень большом числе объектов.
>>На малом числе хостов/сервисов (а 99% всех инсталляций работают с малым числом
>>объектов) никакой существенной разницы между двумя подходами вообще не будет ни
>>по нагрузке на CPU ни по скорости получения отчетов.
>На малом числе узлов zabbix предоставляет более подробную статистику чем nagios.
Расскажите подробней про статистику.
>>При гигантском же числе объектов, имхо zabbix будет сильнее грузить CPU из-за
>>UPDATEов.
>Постоянных Update'ов нет. Update состояния объекта выполняется только при его изменении.
>Если он не менялся не имеет смысла его обновлять. Перестаньте использовать стратегию
>работы с файлами при работе с СУБД. При добавлении данных происходит
>операция INSERT. Плюс вы забываете что СУБД является отдельной от мониторинга
>масштабируемой системой.
Уже ответил выше по поводу UPDATEов/INSERTов.
>>Занятая UPDATEами СУБД будет и трудней отдавать отчеты.
>Мдя... вы с какими СУБД работали а?
С разными, а чем вы хотите возразить?
>>Учтите, что, если у вас гигантское число объектов, то вряд ли вы вообще
>>будете в онлайновом режиме на той же самой машине генерить отчеты
>>за год или два :-)
>Как не странно довольно хорошо генерится. Видимо вы забываете что СУБД бывают
>много потоковыми и они заточены под работу с большими объемами данных.
>>Скорее всего вы захотите слить базу (zabbix) или журналы (nagios) в другое место и там >запустить генерацию отчетов (возможно нестандартных).
>Я уже про это говорил. И уже говорил выше что обычно СУБД
>являются масштабируемыми системами.
>>Я думаю, что решаюшим моментом для большинства пользователей в выборе между двумя
>>данными системами должен стать не вопрос производительности, а вопрос гибкости и
>>масштабируемости.
>Вот тут-то они и возьмут zabbix.
Время покажет :-)
>>Event Broker - это механизм, который позволяет вам скомпилированные объектные файлы >подключать как модули к ядру Nagios.
>В zabbix это не требуется. Там это реализуется через выражения.
На сколько я понимаю, выражения - это средство построения решающего правила для перевода объектов из одного состояния в другое. Какими бы хорошими не были выражения они не смогут реализовать сложный алгоритм.
>>Механизм Event Broker предоставляет легко вешать собственные обработчики на практически >все события, которые происходят в ядре (изменилось состояние объекта, прошла проверка, >ушел дамп в status.dat и т.д.).
>См. выше.
>>Таким образом это ставит точку в споре о гибкости.
>Конечно ставит. Оказывается для того что уже есть в zabbix из коробки
>и делается за 10 минут в nagios требуется писать свой обработчик.
C Event Broker я могу встроиться в самое сердце Nagios и не только обрабатывать но и порождать события. Конечно в повседневной практике это редко кому-то может понадобиться, но если речь заходит о чем-то ну очень экзотичном и нестандартном, то с Nagios можно чуствовать себя, имхо, более свободно.
>>Nagios - это ядро мониторинга, из которого при желании можно слепить абсолютно любую >систему...
>Систему аналогичную zabbix вы не слепите. Разные идеологии и подходы к решению
>одной проблемы.
Любую в смысле решения любой задачи по мониторингу.
>>в том числе без проблем можно заставить те или иные данные уходить в любую СУБД, какую >только пожелает пользователь.
>Какие данные и каким образом? Если это делается парсингом хвоста получаемого от
>плагина то увольте.
Через перехват проверок можно их результаты заносить в СУБД и дальше делать с ними, что угодно (не забывайте что плагины еще имеют инфу на стандартном выводе, что, как полагаю, соответствует слову "данные"). Из нашей с вами дискуссии я почерпнул, что выражения - это большое достоинство zabbix. Будет неплохо, если вы расскажите как эти выражения реально используются и какие задачи реально ими решаются.
