>Давайте уйдем от аксиомы гласящей, что если не используется СУБД, то программа
>плохая и разберемся в вопросе чуть более детально.
Для систем мониторинга неиспользовать СУБД плохо.>Итак у нас есть хосты и сервисы (объекты мониторинга). У каждого объекта есть ряд
>аттрибутов, которые изменяются во времени и, которые необходимо хранить не только
>в памяти, но и на жестком диске, что бы не потерять
>данные о текущем состоянии объектов в момент перезапуска программы. Согласитесь, что
>было бы накладно при каждом перезапуске программы заново составлять базу состояний,
>учитывая если кол-во объектов десятки тысяч. Теперь оценим размер этой базы
>состояний на примере Nagios. Nagios хранит базу состояний в текстовом файле
>status.dat (этот файл используют cgi скрипты) и в retention.dat в примерно
>следующем формате:
>
>объект {
> аттрибут1 значение
> аттрибут2 значение
> ...
> аттрибутN значение
>}
Ну хранятся они в таком формате дальше что?
>У Nagios 2.0b3 объекты host и service файла status.dat занимают в среднем
>1К каждый (чуть больше или чуть меньше в зависимости от plugin_output
>и других переменных величин типа host_name или service_description). Получается что при
>суммарном кол-ве объектов мониторинга в 45000 (см. Top 5 Installations выше)
>требуется памяти не более 50Мб (столько требуется дисковой памяти, а что
>касается ОЗУ, то гораздо меньше, ведь там не надо тратить байты
>на названия аттрибутов).
В СУБД они что больше размером?
>Сам демон не производит никакого парсинга файлов status.dat и retention.dat в процессе
>работы, ему это не надо. Один раз при запуске считывается retention.dat.
Теперь вопрос если я что-то меняю в конфигурации мне надо перезагрузить nagios ?
>В процессе работы переодически делается дамп базы данных состояний из оперативной
>памяти в файлы на HDD. Для retention.dat можно вообще указать, что
>бы в него скидывался дамп лишь в момент останова демона. По-умолчанию
>дамп в retention.dat делается один раз в минуту. Что касается status.dat,
>то по-умолчнию один раз в 15 секунд (задается опцией status_update_interval в
>главном конфиге). Что бы записать 50 Мб на винт обычного IDE
>винчестера требуется не более 2-3 секунд и ресурсы процессора в этой
>операции практически не задействуются.
В zabbix эти данные пишутся только при изменении статуса. Не имеет смысла писать из каждые 15 секунд. Единственное что пишет zabbix постоянно это получаемые данные. И это кстати грузит СУБД довольно слабо.
>Теперь представьте, что Nagios использовал бы СУБД. Это значит, что каждый раз,
>если меняется состояние объекта, надо сделать один или несколько запросов, типа:
>
>UPDATE hosts SET аттрибут1=значение WHERE host_id=12312
>UPDATE hosts SET аттрибут2=значение WHERE host_id=12312
>...
>UPDATE hosts SET аттрибутN=значение WHERE host_id=12312
При наличии СУБД это не требуется делать. Достаточно делать когда что-то поменялось.
>СУБД тратит процессорное время на отработку каждого запроса, в то врмя как
>процессор и без того занят работающими в данный момент плагинами, а
>попробуйте посчитать какова будет загрузка при 45000 объектов мониторинга?
У вас не правильно огранизована работа с СУБД. Это оправдано при работе с файлами но не оправдано при работе с СУБД. Плюс у zabbix большая часть делается внутренним кодом, а не плагинами. Затраты на запуск плагина его остановку и передачу данных учитывать будем или нет ?
>Вывод: с точки зрения производительности использовать текстовый файл, а не СУБД выгодней.
Вывод вы не правильно работаете с СУБД. Может вы перестанете считать что СУБД это такой интерфейс для работы с файлом? СУБД работает с данными. И если вы правильно используете СУБД у вас не будет возникать никаких проблем.
Могу привести следующую доводы:
У nagios веб-интерфейс, туда постоянно ломятся 20-40 человек. СУБД спокойно разрулит эту ситуацию когда что-то в нее пишут и тут же читают. В случае с файлом этого не гарантируется. Тоже самое касается даннных при кластерном решении. В случае если мне необходимо кластерное решение и я использую СУБД она сама разрешит все конфликты запрашивающих сторон. В случае файлов мне прийдется придумывать такой механизм самому. Ну и еще одно. В случае если я использую СУБД мне никто не мешает разнести сам сервер мониторинга и сервер СУБД на разные машины. Причем замечу штатными методами. В случае с nagios мне для достижения аналогичного эффекта надо будет заюзать iSCSI-технологию к примеру. Да и то от операций по записи в файл процессор разгружен не будет.
