>>Получается что при
>>суммарном кол-ве объектов мониторинга в 45000 (см. Top 5 Installations выше)
>>требуется памяти не более 50Мб
>В СУБД они что больше размером? Не надо рассматривать каждый тезис, как покушение на zabbix или СУБД.
Просто когда мы имеем конкретную цифру, то можно более предметно рассуждать о производительности.
Вот у нас есть цифра 50 Мб против 45000 объектов и ладно, а чуть больше или чуть меньше это в СУБД не суть важно.
>>Сам демон не производит никакого парсинга файлов status.dat и retention.dat в процессе
>>работы, ему это не надо. Один раз при запуске считывается retention.dat.
>Теперь вопрос если я что-то меняю в конфигурации мне надо перезагрузить nagios
>?
kill -HUP будет достаточно
>>Что касается status.dat,
>>то по-умолчнию один раз в 15 секунд (задается опцией status_update_interval в
>>главном конфиге)
>В zabbix эти данные пишутся только при изменении статуса. Не имеет смысла
>писать из каждые 15 секунд. Единственное что пишет zabbix постоянно это
>получаемые данные. И это кстати грузит СУБД довольно слабо.
СУБД ориентированый подход и то, как устроен Nagios - это все таки разные вещи.
В случае с СУБД действительно не имеет смысл что-то там записывать каждые 15 секунд, а вот Nagios должен поддерживать актуальность данных status.dat и для этого он делает дамп через промежутки времени заданые опцией status_update_interval главного конфига (не обязательно 15 сек.). Ведь каждая совершившаяся проверка с собой приносит новую информацию и даже, если объект не изменил своего состояния и по-прежнему нормально пингуется (или по-прежнему ненормально не пингуется :), как бы там ни было после проверки мы имеем новую информацию об RTA и кол-ве потерянных пакетов и должны это зафиксировать в БД в случае с zabbix.
И получается, что после каждой проверки zabbix шлет миниммум один UPDATE в СУБД, а Nagios не зависимо от кол-ва совершившихся проверок каждые 15 сек. (или сколько скажете) обновляет status.dat.
>>Теперь представьте, что Nagios использовал бы СУБД. Это значит, что каждый раз,
>>если меняется состояние объекта, надо сделать один или несколько запросов, типа:
>>UPDATE hosts SET аттрибут1=значение WHERE host_id=12312
>При наличии СУБД это не требуется делать. Достаточно делать когда что-то поменялось.
Будьте внимательны, я ведь так и написал: "каждый раз, если меняется состояние объекта"...
На деле zabbix должен обновлять данные в БД после каждой проверки, даже если само состояние объекта осталось прежним (см. выше).
>>СУБД тратит процессорное время на отработку каждого запроса, в то врмя как
>>процессор и без того занят работающими в данный момент плагинами, а
>>попробуйте посчитать какова будет загрузка при 45000 объектов мониторинга?
>У вас не правильно огранизована работа с СУБД. Это оправдано при работе
>с файлами но не оправдано при работе с СУБД.
У нас Nagios, который не использует СУБД и сам по себе не грузит процессор, а zabbix неизбежно делает UPDATEы после каждой проверки.
Давайте попробуем посчитать.
Представим, что у нас есть 5000 хостов и у каждого хоста есть сервис, который должен проверяться ежеминутно. Получается, что каждую минуту делается 5000 проверок, что составляет ~83 проверки в секунду. В случае СУБД ориентированного подхода это выливается в минимум 83 UPDATEа в секунду нагрузки на СУБД. По-моему это может заставить систему призадуматься :-)
>Плюс у
>zabbix большая часть делается внутренним кодом, а не плагинами. Затраты на
>запуск плагина его остановку и передачу данных учитывать будем или нет
>?
Расходы на запуск бинарного файла не велики, а что касается плагинов на Perl, то можно собрать Nagios с ключиком --enable-embedded-perl.
>>Вывод: с точки зрения производительности использовать текстовый файл, а не СУБД выгодней.
>Вывод вы не правильно работаете с СУБД. Может вы перестанете считать что
>СУБД это такой интерфейс для работы с файлом? СУБД работает с
>данными. И если вы правильно используете СУБД у вас не будет
>возникать никаких проблем.
По-моему мои доводы обоснованы и объективны, я привел простые расчеты и ни в одном месте не дал повод думать будто для меня СУБД - это интерфейс работы с файлом. Модель объектов мониторинга и аттрибутов действует для любого подхода.
>Могу привести следующую доводы:
>У nagios веб-интерфейс, туда постоянно ломятся 20-40 человек. СУБД спокойно разрулит эту
>ситуацию когда что-то в нее пишут и тут же читают. В
>случае с файлом этого не гарантируется. Тоже самое касается даннных при
>кластерном решении. В случае если мне необходимо кластерное решение и я
>использую СУБД она сама разрешит все конфликты запрашивающих сторон. В случае
>файлов мне прийдется придумывать такой механизм самому. Ну и еще одно.
>В случае если я использую СУБД мне никто не мешает разнести
>сам сервер мониторинга и сервер СУБД на разные машины. Причем замечу
>штатными методами. В случае с nagios мне для достижения аналогичного эффекта
>надо будет заюзать iSCSI-технологию к примеру. Да и то от операций
>по записи в файл процессор разгружен не будет.
Дампу объектов в status.dat будет достаточно обычного IDE винта и при четверти миллиона объектов (расчеты я приводил) :-)))
Для того, что бы отобразить список хостов и/или сервисов Nagios должен открыть для чтения и пропарсить status.dat размером 50 Мб (если мы говорим о 45000 объектах). Бинарный cgi скрипт легко с этим справится, долго ждать не придется. Тот факт, что несколько юзеров одновременно запросят данную операцию тоже проблем не вызовет. Nagios обеспечивает по выбору суточную, недельную или ежемесячную ротацию журналов - это дает возможность ускорить обработку и выдачу результатов по отчетам за короткий промежуток времени (именно такого типа отчеты чаще всего используются).
Словом по-моему нет никаких мегаминусов связаных с тем, что nagios не использует СУБД.
На малом числе хостов/сервисов (а 99% всех инсталляций работают с малым числом объектов) никакой существенной разницы между двумя подходами вообще не будет ни по нагрузке на CPU ни по скорости получения отчетов.
При гигантском же числе объектов, имхо zabbix будет сильнее грузить CPU из-за UPDATEов. Занятая UPDATEами СУБД будет и трудней отдавать отчеты. Учтите, что, если у вас гигантское число объектов, то вряд ли вы вообще будете в онлайновом режиме на той же самой машине генерить отчеты за год или два :-) Скорее всего вы захотите слить базу (zabbix) или журналы (nagios) в другое место и там запустить генерацию отчетов (возможно нестандартных).
Я думаю, что решаюшим моментом для большинства пользователей в выборе между двумя данными системами должен стать не вопрос производительности, а вопрос гибкости и масштабируемости.
В вопросе гибкости я за Nagios и здесь время еще раз вспомнить про Event Broker.
Event Broker - это механизм, который позволяет вам скомпилированные объектные файлы подключать как модули к ядру Nagios.
Механизм Event Broker предоставляет легко вешать собственные обработчики на практически все события, которые происходят в ядре (изменилось состояние объекта, прошла проверка, ушел дамп в status.dat и т.д.). Таким образом это ставит точку в споре о гибкости. Nagios - это ядро мониторинга, из которого при желании можно слепить абсолютно любую систему... в том числе без проблем можно заставить те или иные данные уходить в любую СУБД, какую только пожелает пользователь.
