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