В новой версии Nagios 2.4 (http://www.nagios.org/) исправлена проблема связанная с крахом cgi-скриптов (по SIGBUS) при чтении файлов со статусом, комментариями или информацией о времени активной работы.
Также устранено некорректное поведение скрипта handle-master-proc-event, восстановлена возможность сборки под Solaris, улучшена информативность сообщений об ошибках в CGI скриптах, в make-файл добавлена опция установки (install-unstripped) без чистки отладочной информации в исполняемых файлах.URL: http://www.nagios.org/
Новость: http://www.opennet.me/opennews/art.shtml?num=7649
сколько одновременно серверов может обслуживать эта софтина?
1-ая версия. ~350 хостов, ~400 сервисов. Xeon 2.4, 2G RAM
Про второй не скажу, а с первого мониторю ~100 хостов, ~650 сервисов. Тачка - Celeron 300/ 128 MB RAM / FreeBSD 4.10.
nagios-2.0b1почти 500 хостов, чуть больше 2000 сервисов
quoted from www.nagios.org:Top 5 Installations By # Of Hosts
# of Hosts Organization Org. Type Country
5000 ITI e Dataprev Government Brazil
3500 ErgoGroup Corporation Norway
3000 Time Warner Cable San Antonio Corporation United States of America
3000 Saudi Electricity Company Other Saudi Arabia
2700 Müller Ltd.&Co.KG Corporation Germany
Top 5 Installations By # Of Services# of Services Organization Org. Type Country
40000 Müller Ltd.&Co.KG Corporation Germany
40000 ConSol Corporation Germany
40000 GMM GRAMMY Other Thailand
35000 ErgoGroup Corporation Norway
23441 World Gaming PLC Corporation United Kingdom
юзайте netmond, весч!
Только zabbix!Машина 2x3.2Ghz 1Gb. load average: 0.34, 0.36, 0.27
40 серверов 1506 мониторящихся параметров. База mysql 4Gb, история изменения пораметров храниться неделю. php интерфейс + темплейты.
И т.д. ....
>Машина 2x3.2Ghz 1Gb. load average: 0.34, 0.36, 0.27Эта строка сказала мне все =) у мя такое же ЛА на машинке с 1700 атлон хр(1100МГц) и 256 метров оперативки, а крутится на той тачке только роутер/сквид(на двух человек) и web с посещаемостью 5 человек в час =) Только я считаю, что я не до конца напряг машинку, она реально вытянет гораздо большее, особенно если память добавить. А тут мониторинг 40 хостов якобы перегружает машинку, ЛА в пике у которой может быть до 60, а то и выше =) Но 0.34 системку перегревает =)
забавный камент, в общем
Ага - чтобы мониторить 40 серваков нужен 2х-головый монстр :) Тогда да - только зябиихс. :)))
>Ага - чтобы мониторить 40 серваков нужен 2х-головый монстр :) Тогда да
>- только зябиихс. :)))
Для nagios надо. Для zabbix и пня 3 хватит. ;) Только вы еще про СУБД забываете.
как правильно настроить nagios?
Курите доки :)В принципе, можно начать именно со скурения доков :)
Распечатать, скурить :) Проспаться. И понеслась... Со всеми остановками... :)
Маны, гугель, тихое бешенство: "что,жалкобыловыложить???"
Победная лень... леньбудетвыложить...
Кстати, выложите, пожалукйста, тостер!
Посмотрел я эти netmond и zabbix.
По-моему Nagios лучше гораздо и, что самое важное, гибче.
Nagios - это система промышленного, я бы сказал, масштаба. Сотни хостов мониторить - вообще не проблема, супер-пупер сервер не нужен никакой. Nagios использую давно и опыт имеется только положительный, устраивает полностью. Сейчас для одного из местных университетов мониторинг внедряю, за сотню хостов и сервисов под тыщу будет.
>Посмотрел я эти netmond и zabbix.
>По-моему Nagios лучше гораздо и, что самое важное, гибче.
Гибче ? Это вы неправильно смотрите. Для сети с большим количеством устройств с поддержкой snmp в качестве managment протокола Nagios будет крайне не удобен.>Nagios - это система промышленного, я бы сказал, масштаба.
извините но почему эта система промышленного масштаба использует в качестве хранилища не СУБД, а файловую систему? Это что быстрее ? Практика показывает, что нет. А еще мне понравились их предложения по повышению производительности. Вынести файловое хранилище системы мониторинга на RAM-диск это что-то! И что самое главное надежно в промышленной эксплуатации.>Сотни хостов мониторить - вообще не проблема, супер-пупер сервер не нужен никакой.
В zabbix тоже нет проблемы. Сходите на форум zabbix почитайте :) Народ им 2000 серверов и 10000 сервисов причем на раз.>Nagios использую давно и опыт имеется только положительный, устраивает полностью.
Используйте на здоровье.>Сейчас для одного из местных университетов мониторинг внедряю, за сотню хостов и сервисов под тыщу будет.
У меня в zabbix:
Number of hosts 102
Number of items 1718Причем еще не все добавлено. Кроме zabbix на машине еще много чего крутится.
Кстати zabbix анализирует данные, в отличие от Nagios. Nagios же анализирует состояния. У nagios неудача, в том что все данные анализируются в плагинах и для изменения их поведения может потребоваться лезть в код. В zabbix этого не требуется. Там тревоги задаются через выражения. Плюс когда мы хотим графики в nagios... приходится прикручивать сторонние средства да и при этом аналогичного функционала не получим. Аналогичным функционалом по графикам из opensource обладает только cacti.
те могли-бы вы подсказать есть-ли в zabbix возможность автоматизировать добавленеие пары десятков однотимпных хостов, не тратя время на кликанье в веб-нитерфейсе? (напр. возможность прямого редактирования конфигурации )
да еще в zabbix клиента надо расставлять везде...
>да еще в zabbix клиента надо расставлять везде...
Заблуждение. Zabbix отлично работает с snmp. Кроме этого есть возможность слать trap's при помощи zabbix_sender. Агентов можно ставить но далеко не обязательно. Плагины ведь тоже надо ставить ?
>те могли-бы вы подсказать есть-ли в zabbix возможность автоматизировать добавленеие пары >десятков однотимпных хостов, не тратя время на кликанье в веб-нитерфейсе? (напр. >возможность прямого редактирования конфигурации )
есть шаблоны. Заводите один раз шаблон и привязываете на него. Плюс есть bulk loader который позволяет загружать и выгружать узлы.
>Кстати zabbix анализирует данные, в отличие от Nagios. Nagios же анализирует состояния.
>У nagios неудача, в том что все данные анализируются в плагинах
>и для изменения их поведения может потребоваться лезть в код. В
>zabbix этого не требуется. Там тревоги задаются через выражения. Плюс когда
>мы хотим графики в nagios... приходится прикручивать сторонние средства да и
>при этом аналогичного функционала не получим. Аналогичным функционалом по графикам из
>opensource обладает только cacti.В плане удобства и дружелюбности пользовательского интерфейса наверное Nagios проигрывает.
Я бы не стал столь категорично называть неудачей тот факт, что сами плагины принимают решение о том, в каком состоянии находится сервис. В чем здесь проблма-то? Как правило у любого плагина есть ключи с помощью которых делается тонкая настройка порога переходв в WARNING и CRITICAL. Я лично с этим вообще проблем не испытываю. Понадобилось что-нить нестандартное - взял написал плагин, сделал, что надо. Все просто и понятно, чего тут огород городить. Это и есть та самая гибкость, которая позволяет реализовывать самые нестандартные проверки и методы уведомления.
А еще у Nagios Event Broker есть, вот так :-)
>Я бы не стал столь категорично называть неудачей тот факт, что сами
>плагины принимают решение о том, в каком состоянии находится сервис.
А я бы стал. Если у вас 200 серверов и надо мониторить их состояние и надо поменять всего один параметр то это может стать ой как актуально.>В чем здесь проблма-то? Как правило у любого плагина есть ключи с
>помощью которых делается тонкая настройка порога переходв в WARNING и CRITICAL.
А если мне надо поменять сам алогритм перехода WARNING в CRITICAL. В zabbix меняю выражение и все. В nagios долго упорно ковыряюсь в плагине.>Я лично с этим вообще проблем не испытываю. Понадобилось что-нить нестандартное
>- взял написал плагин, сделал, что надо. Все просто и понятно,
>чего тут огород городить.
Простота палка о двух концах.>Это и есть та самая гибкость, которая позволяет реализовывать самые нестандартные проверки и методы уведомления.
В zabbix это делается гараздо проще и удобнее. Необходимо только подумать как передать данные zabbix серверу. Далее настройка проверок и уведомлений выполняется в самом zabbix.>А еще у Nagios Event Broker есть, вот так :-)
А что он умеет делать и зачем?
А для графиков я RRDTool'ом пользуюсь. Он с MRTG дружит, если самому лень скрипты писАть.ИМХО большой косяк zabbix в том, что конфигурится он через кликанье в интерфейсе.
Конфиги все же - это правильней. Можно, например, в домене авторегистрацию замутить. В домен вводится новая рабочая станция -> автоматически применяется групповая политика, которая на этой новой рабочей станции запускает скрипт -> скрипт в нужном месте создает типовой конфиг -> перезапуск демона и вуаля -> машина у нас под наблюдением. Сможете такое в zabbix? В конфигах шаблоны позволяют все упростить. Скажем тот же типовой конфиг для новой машины домена мог бы выглядеть так:
define host{
use host-templatename new-workstation
alias MAC addres 00-08-a3-7d-d6-8f
address 192.168.1.1
}define service{
use service-templatehost_name new-workstation
service_description PING
}Еще несомненное достоинство в том, что в поле address _НЕ_ОБЯЗАТЕЛЬНО_ должен быть IP адрес. На самом деле то, что вы там напишите в дальнейшем просто подставляется вместо макроса $HOSTADDRESS$ при опрделении команд. То есть получается, что указанное в address в конечном счете передается в качестве аргумента плагину, а уж как плагин будет это интерпретировать... Я вот собираюсь написАть плагин которому будет передаваться список IP адресов. Предполагается, что есть хост, у которого много IP-адресов и плагин будет умно каждый проверять и делать CRITICAL только в том случае, если ни один из адресов не пингуется; OK, если пингуются все и WARNING если не пигуется лишь часть адресов.
Интересно как вы решаете задачу мониторинга подобных хостов в zabbix? А как дела обстоят с зависимостями сервисов друг от друга? А есть ли понятие пассивных проверок?
>А для графиков я RRDTool'ом пользуюсь. Он с MRTG дружит, если самому
>лень скрипты писАть.
Ну-ну. Хотел бы я посмотреть как вы будете масштабировать графики с их помощью. Аналогично zabbix с графиками умеет работать cacti.>
>ИМХО большой косяк zabbix в том, что конфигурится он через кликанье в
>интерфейсе.
builk loader еще никто не отменял.>Конфиги все же - это правильней. Можно, например, в домене авторегистрацию замутить. В домен вводится новая рабочая станция -> автоматически применяется групповая политика, которая на этой новой рабочей станции запускает скрипт -> скрипт в нужном месте создает типовой конфиг -> перезапуск демона и вуаля -> машина у нас под наблюдением. Сможете такое в zabbix?
Конечно. Вся конфигурация хранится в базе данных что мне мешает добавить вне необходимое ? Ничего.
В конфигах шаблоны позволяют все упростить.
Шаблоны в zabbix есть.>Еще несомненное достоинство в том, что в поле address _НЕ_ОБЯЗАТЕЛЬНО_ должен быть
>IP адрес. На самом деле то, что вы там напишите в
>дальнейшем просто подставляется вместо макроса $HOSTADDRESS$ при опрделении команд. То есть
>получается, что указанное в address в конечном счете передается в качестве
>аргумента плагину, а уж как плагин будет это интерпретировать... Я вот
>собираюсь написАть плагин которому будет передаваться список IP адресов. Предполагается, что
>есть хост, у которого много IP-адресов и плагин будет умно каждый
>проверять и делать CRITICAL только в том случае, если ни один
>из адресов не пингуется; OK, если пингуются все и WARNING если
>не пигуется лишь часть адресов.
Это фича которая по сути дела не нужна. В zabbix 1.1_beta12 есть возможность указать привяку ip и items к приложению (сервису). Это как мне кажется как раз тоже самое.
>Интересно как вы решаете задачу мониторинга подобных хостов в zabbix?
У меня на данный момент такой задачи не стоит. Если будет стоять см. выше.>А как дела обстоят с зависимостями сервисов друг от друга? А есть ли
>понятие пассивных проверок?
Зависимости есть. Что вы подразумеваете под пассивными проверками.
Еще раз повторюсь основная неудача nagios это хранение данных в файлах. Это сказывается на его производительности.
>>А как дела обстоят с зависимостями сервисов друг от друга? А есть ли
>>понятие пассивных проверок?
>Зависимости есть. Что вы подразумеваете под пассивными проверками.Пассивная проверка - это когда нет какого-то теста, который сама программа мониторинга активно запускает согласно расписанию, а вместо этого результат проверки приходит из вне.
Например у меня на Windows сервере скрипт парсит определенный лог и ему надо каким-то образом сообщить результат в Nagios. Для этого в Nagios создается сервис и ему задается тип passive, что означает, что Nagios не должен сам никак этот сервис проверять, а результат о состоянии сервиса ему пришлют из вне.>Еще раз повторюсь основная неудача nagios это хранение данных в файлах. Это
>сказывается на его производительности.Данный вопрос подробно рассмотрен в другом посте и получается, что как раз наоборот производительность не только не страдает, а еще и выигрывает от файлов.
>>Nagios - это система промышленного, я бы сказал, масштаба.
>извините но почему эта система промышленного масштаба использует в качестве хранилища не
>СУБД, а файловую систему? Это что быстрее ? Практика показывает, что
>нет. А еще мне понравились их предложения по повышению производительности. Вынести
>файловое хранилище системы мониторинга на RAM-диск это что-то! И что самое
>главное надежно в промышленной эксплуатации.Давайте уйдем от аксиомы гласящей, что если не используется СУБД, то программа плохая и разберемся в вопросе чуть более детально. Итак у нас есть хосты и сервисы (объекты мониторинга). У каждого объекта есть ряд аттрибутов, которые изменяются во времени и, которые необходимо хранить не только в памяти, но и на жестком диске, что бы не потерять данные о текущем состоянии объектов в момент перезапуска программы. Согласитесь, что было бы накладно при каждом перезапуске программы заново составлять базу состояний, учитывая если кол-во объектов десятки тысяч. Теперь оценим размер этой базы состояний на примере 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. В процессе работы переодически делается дамп базы данных состояний из оперативной памяти в файлы на HDD. Для retention.dat можно вообще указать, что бы в него скидывался дамп лишь в момент останова демона. По-умолчанию дамп в retention.dat делается один раз в минуту. Что касается status.dat, то по-умолчнию один раз в 15 секунд (задается опцией status_update_interval в главном конфиге). Что бы записать 50 Мб на винт обычного IDE винчестера требуется не более 2-3 секунд и ресурсы процессора в этой операции практически не задействуются.
Теперь представьте, что 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 объектов мониторинга?
Вывод: с точки зрения производительности использовать текстовый файл, а не СУБД выгодней.
>Давайте уйдем от аксиомы гласящей, что если не используется СУБД, то программа
>плохая и разберемся в вопросе чуть более детально.
Для систем мониторинга неиспользовать СУБД плохо.>Итак у нас есть хосты и сервисы (объекты мониторинга). У каждого объекта есть ряд
>аттрибутов, которые изменяются во времени и, которые необходимо хранить не только
>в памяти, но и на жестком диске, что бы не потерять
>данные о текущем состоянии объектов в момент перезапуска программы. Согласитесь, что
>было бы накладно при каждом перезапуске программы заново составлять базу состояний,
>учитывая если кол-во объектов десятки тысяч. Теперь оценим размер этой базы
>состояний на примере 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-технологию к примеру. Да и то от операций по записи в файл процессор разгружен не будет.
смотрел zabbix. задумка офигенная конечно..но остановился на nagios
основным фактором причем стало то что zabbix не умеет (или я не нашел?) автоматически отрисовать карту хостов.. ручками пару сотен хостов на его map расставлять - убится можно
>>Получается что при
>>суммарном кол-ве объектов мониторинга в 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 - это ядро мониторинга, из которого при желании можно слепить абсолютно любую систему... в том числе без проблем можно заставить те или иные данные уходить в любую СУБД, какую только пожелает пользователь.
>Не надо рассматривать каждый тезис, как покушение на 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 вы не слепите. Разные идеологии и подходы к решению одной проблемы.>в том числе без проблем можно заставить те или иные данные уходить в любую СУБД, какую >только пожелает пользователь.
Какие данные и каким образом? Если это делается парсингом хвоста получаемого от плагина то увольте.
>>Не надо рассматривать каждый тезис, как покушение на 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. Будет неплохо, если вы расскажите как эти выражения реально используются и какие задачи реально ими решаются.
>Вы какой-то непонятливый. По-моему это очевидно, что цифра нужна для оценки производительности.Вы странно меряете производительность. 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. Будет неплохо, если вы расскажите как эти выражения реально используются
>и какие задачи реально ими решаются.
Выражения используются для задания триггеров генераторов событий. Пример использования я уже привел выше.
Ладно вам спорить, в соседней ветке про Zabbix 1.1, кто-то статистику привел, при 40 хостах и 1500 параметрах мониторинга, история за неделю занимает 4.5 Гб. Этим все сказано.У меня в 20 раз больше хостов на nagios, машина Celeron 800 со 128 Мб памяти, размер полной истории за 2 года - 250 Мб (в историю nagios помещает только изменение состояния, а не дублирует одно и тоже).
Про трудность интеграции nagios с другими системами тоже бред, за день был написан скрипт для полной синхронизации базы клиентов из биллинга.
>Ладно вам спорить, в соседней ветке про Zabbix 1.1, кто-то статистику привел,
>при 40 хостах и 1500 параметрах мониторинга, история за неделю занимает
>4.5 Гб. Этим все сказано.
Ничего удивительного. Zabbix работает с данными, а не с событиями.>У меня в 20 раз больше хостов на nagios, машина Celeron 800
>со 128 Мб памяти, размер полной истории за 2 года -
>250 Мб (в историю nagios помещает только изменение состояния, а не
>дублирует одно и тоже).
Вы тоже не понимаете разницу между тем как работает nagios и как работает zabbix. У вас есть архив событий, а не архив данных который можно анализировать различным образом. Самый простой пример это построение графиков. Всем поклонникам Nagios стоит посмотрить что такое SCADA и как оно работает.>Про трудность интеграции nagios с другими системами тоже бред, за день был
>написан скрипт для полной синхронизации базы клиентов из биллинга.
Интеграции чего с чем? Что с чем синхронизировалось?
>Вы тоже не понимаете разницу между тем как работает nagios и как
>работает zabbix. У вас есть архив событий, а не архив данных
>который можно анализировать различным образом. Самый простой пример это построение графиков.Я прекрасно понимаю, что по архиву событий можно без проблем воссоздать недетализированное состояние хоста в любой момент, только вот SQL на это не заточен. А для графиков есть rrd, что тоже на порядок эффективнее выборок из СУБД. Итог - в zabbix пошли простым, но не эффективным путем.
>>Про трудность интеграции nagios с другими системами тоже бред, за день был
>>написан скрипт для полной синхронизации базы клиентов из биллинга.>Интеграции чего с чем? Что с чем синхронизировалось?
Список машин и сервисов, которые нужно мониторить.
>Я прекрасно понимаю, что по архиву событий можно без проблем воссоздать недетализированное
>состояние хоста в любой момент, только вот SQL на это не
>заточен.
Тогда можно поинтересоваться под что заточен SQL? Причем тут вообще SQL? Говорится вообще-то о СУБД. А SQL это лишь язык работы с ней.>А для графиков есть rrd, что тоже на порядок эффективнее
>выборок из СУБД.
Насколько я помню rrd по сути представляет собой бинарный файл с timestamp + данные. Чем это отличается таблицы в СУБД и чем это эффективнее?>Итог - в zabbix пошли простым, но не эффективным путем.
В zabbix пошли правильным путем. Практически всю работу с данными переложили на СУБД.>Список машин и сервисов, которые нужно мониторить.
В zabbix это так же не видится сложным. Я бы сказал там это даже проще.
>Я прекрасно понимаю, что по архиву событий можно без проблем воссоздать недетализированное
>состояние хоста в любой момент, только вот SQL на это не
>заточен. А для графиков есть rrd, что тоже на порядок эффективнее
>выборок из СУБД. Итог - в zabbix пошли простым, но не
>эффективным путем.
Да вы что? А там про процедуры и триггеры внутри СУБД не слышали?? Скажите зачем мне писать парсер фалов, затем еще анализатор, затем ещё склеивать результат и выводить его? Вы думаете это быстрее сделать на стороне мониторинга или же на стороне СУБД? Я уже молчу про то, что если у вас есть мощный сервер/кластер БД, то вы можете данные там хранить, что упростит процедуру бекапа. Я вот думаю, что при использовании процедур получить нужный вам результат для форматирования будет быстрее, а главное ядро системы мониторинга не будет заниматься фигнеё типа распарсивания логов или ему заняться нечем? Кстати вопрос - неужели работать с бинарным файлом в 50 мегов быстрее чем с БД при постоянных запросах?
По поводу размещения диска в памяти, а что будет, если у вас память гикнется??? Или сервак вырубится? Ну и конечно же зачем резать память у сервера, когда она ему понадобится при обработке данных?
>Ладно вам спорить, в соседней ветке про Zabbix 1.1, кто-то статистику привел,
>при 40 хостах и 1500 параметрах мониторинга, история за неделю занимает
>4.5 Гб. Этим все сказано.
>
>У меня в 20 раз больше хостов на nagios, машина Celeron 800
>со 128 Мб памяти, размер полной истории за 2 года -
>250 Мб (в историю nagios помещает только изменение состояния, а не
>дублирует одно и тоже).
>
>Про трудность интеграции nagios с другими системами тоже бред, за день был
>написан скрипт для полной синхронизации базы клиентов из биллинга.Т.е. достаточно одного скрипта, чтобы синхронизировать нагиос с БД?
А можно ли еще прикрутить к нему snort, cаcti?очень хочется связать в единое целое эти компоненты для мониторинга, управления
и контроля в сети из 3-4 тыс хостов и до 100 единиц оборудования(серверов, коммутаторов, роутеров).
>Вынести
>файловое хранилище системы мониторинга на RAM-диск это что-то! И что самое
>главное надежно в промышленной эксплуатации.Вы неправильно поняли сути того, что предлагается.
Предлагается не файловое хранилище (журналы) выносить в RAM-диск, а файлик status.dat, который содержит текущее состояние объектов мониторинга и служит единственной цели - его по запросу пользователей парсят CGI скрипты для того, что бы нарисовать карту или просто вывести список хостов/сервисов с их состояниями. Естесственно, что делать регулярный дамп файла в RAM-диск и читать в процессе парсинга из RAM-диска много быстрей, чем с HDD. Однако это все для тех у кого объектов ну очень много (десятки тысяч).
>Плюс когда
>мы хотим графики в nagios... приходится прикручивать сторонние средства да и
>при этом аналогичного функционала не получим. Аналогичным функционалом по графикам из
>opensource обладает только cacti.opensource даёт некоторые возможности...
У меня демон в онлайне распихивает данные из Nagios-овского perflog-а по rrd базам. А для отображалки как раз взял javascript-ы от cacti. Ничего сложного. Всё маштабируется и настраивается как угодно.
>opensource даёт некоторые возможности...
>У меня демон в онлайне распихивает данные из Nagios-овского perflog-а по rrd
>базам. А для отображалки как раз взял javascript-ы от cacti. Ничего
>сложного. Всё маштабируется и настраивается как угодно.А теперь ответьте сколько вы времени на это убили ? И документировали ли это ? В zabbix это является частью стандартной системы.
Я поставил себе zabbix, появилось несколько вопросв.
Вы, я понял очень подкованы в этом вопросе. Немогли бы помоч.
-Не подкажете можно ли где-то найти документацию на русском.
-Как правильно настраивать Тригеры
-рисование карты общей ( умеет ли автоматически отрисовать карту хостов)
>Я поставил себе zabbix, появилось несколько вопросв.
>Вы, я понял очень подкованы в этом вопросе. Немогли бы помоч.
>-Не подкажете можно ли где-то найти документацию на русском.
>-Как правильно настраивать Тригеры
>-рисование карты общей ( умеет ли автоматически отрисовать карту хостов)Документации и на английском нормальной нет :)
Карту сама не рисует - надо руками всё проставлять, причём с масштабируемостью карты очень плохо.
Я сейчас как раз эти 2 системы сравниваю - с моей точки зрения задумка у забикса хорошая, только вот кривая она пока, аж жуть.
Создал карту - удалил, после создал другую- она вообще перестала отображаться, пишет что карты с индексом 1 нет, а новые карты создаются с инкрементным индексом - глюк.
С IT service - тоже куча глюков.
Русский не подцепляется, хотя может только у меня такая проблема ?
Да и фрей он плохо дружит.
Если из портов ставить - по умолчанию все скрипты кривые - переделывать надо.
А вот задумка со скринами хорошая.Вобшем мой выбор - нагиос, на забикс посморю к версии 1.4 , может улучшат :)
ps: да, и автору забикса на форум забивает :)))
>>Я поставил себе zabbix, появилось несколько вопросв.
>>Вы, я понял очень подкованы в этом вопросе. Немогли бы помоч.
>>-Не подкажете можно ли где-то найти документацию на русском.
>>-Как правильно настраивать Тригеры
>>-рисование карты общей ( умеет ли автоматически отрисовать карту хостов)
>
>Документации и на английском нормальной нет :)
>Карту сама не рисует - надо руками всё проставлять, причём с масштабируемостью
>карты очень плохо.
>Я сейчас как раз эти 2 системы сравниваю - с моей точки
>зрения задумка у забикса хорошая, только вот кривая она пока,
>аж жуть.
>Создал карту - удалил, после создал другую- она вообще перестала отображаться, пишет
>что карты с индексом 1 нет, а новые карты создаются с
>инкрементным индексом - глюк.
>С IT service - тоже куча глюков.
>Русский не подцепляется, хотя может только у меня такая проблема ?
>Да и фрей он плохо дружит.
>Если из портов ставить - по умолчанию все скрипты кривые - переделывать
>надо.
>А вот задумка со скринами хорошая.
>
>Вобшем мой выбор - нагиос, на забикс посморю к версии 1.4 ,
>может улучшат :)
>
>ps: да, и автору забикса на форум забивает :)))Я настроил меня устраивает
то что я хотел у меня все работает
Nagios - даже не смотрел у меня все данные по snmp собираются, Читал что замучиежся писать конфиг. По поводу скриптов, ничего будем повышить свой опыт :).
Мне что нравится в zabbix он весь web-интерфейс. Тоесть что бы добовлять оборудование онвое больших знаний не надо, можно поручить любому:).
народ подскажите, может ли nagios проверить скорость канала до удаленного хоста?