Анонсирован (http://www.icinga.org/2010/10/06/icinga-1-2-unified-stable-r.../) релиз открытой системы мониторинга Icinga 1.2.0 (http://www.icinga.org/), которая представляет собой форк системы мониторинга Nagios, отделившийся в начале мая 2009 года вследствие конфликта (https://www.opennet.ru/opennews/art.shtml?num=28121) независимых разработчиков с компанией Nagios Enterprises, основанной создателем проекта. Исходные тексты Icinga распространяются в рамках лицензии GPL.
Ключевым новшеством представленного релиза является интеграция нового более гибкого и удобного web-интерфейса, имеющего модульную архитектуру, переписанного на языке PHP, активно использующего современные web-технологии, такие как AJAX, и представляющего статистику в виде графиков. Интерфейс может настраиваться через шаблоны и расширяться через дополнения. Для обеспечения интеграции с внешними сервисами предусмотрено несколько API: XML, JSON, SOAP.<center><a href="http://www.icinga.org/wp-content/uploads/...
URL: http://www.icinga.org/2010/10/06/icinga-1-2-unified-stable-r.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=28197
Несколько лет уже использую Munin (серверов порядка 10-12), есть ли кто-нибудь, который знаком и с сабжем и с мунином? Если да, стоит ли тратить время и перебраться на сабж и за какими выгодами?
> Если да, стоит лиСлушай анекдот и запоминай его:
Админ, приклеившись носом к монитору.
Сынишка 5-ти лет.
-- Папа, папа! А почему солнышко утром восходит, а вечером заходит?
-- Ты уверен?
-- Да!
-- Ничего не трогай!!!
>> Если да, стоит ли
> Слушай анекдот и запоминай его:
> Админ, приклеившись носом к монитору.
> Сынишка 5-ти лет.
> -- Папа, папа! А почему солнышко утром восходит, а вечером заходит?
> -- Ты уверен?
> -- Да!
> -- Ничего не трогай!!!+1
Менять стоит только в том случае, если существующая система вас не устраивает.
А если просто хочется новых ощущений...
# echo "oh yea" > /etc/password
И бегом в серверную =)
как-то вы мимо кассы нынче. нагиос (исинга) и мунин совершенно разные продукты, если нужно мониторить сервера постоянно, а не время от времени графики смотреть, и узнавать от юзеров, что у тебя уже как час лежит какой-нить сервис, то нагиос очень даже. и совсем другой компот, что с помощью pnp, в нагиосе, можно тоже графики рисовать.
> как-то вы мимо кассы нынче. нагиос (исинга) и мунин совершенно разные продукты,
> если нужно мониторить сервера постоянно, а не время от времени графики
> смотреть, и узнавать от юзеров, что у тебя уже как час
> лежит какой-нить сервис, то нагиос очень даже. и совсем другой компот,
> что с помощью pnp, в нагиосе, можно тоже графики рисовать.Я в кассу.
У человека уже есть настроенная и рабочая среда.
Т.е. у него есть потребности, которые эта среда удовлетворяет.
И переходить на новую, которая как вы описали - совершенно разный продукт, нужно только в том случае, если текущая среда не удовлетворяет потребностям.
# echo "oh yea" > /dev/hda1
> # echo "oh yea" > /dev/hda1Ну и что там такого невосстановимого в первых шести байтах раздела?
7 байтах ;)
> 7 байтах ;)Подловил :)
> # echo "oh yea" > /dev/hda1От этого ваш сервер продолжить работу.
И можно даже удаленно починить.А если вы похерите /etc/passwd, могут перестать запускаться многие процессы.
И вы тупо уже не зайдете по ssh.
А потом pwd_mkdb -p /etc/master.passwd
Учитесь отращивать админское брюхо, молодой человек.
И даже после этого ничего не произойдёт. :) А всё потому что исходный файл будет в левом виде.
man pwd_mkdb:
===
The file must be in the correct format (see
passwd(5)).
===Я даже это дело опробовал сейчас. Как и ожидалось, защита от дурака работает :)
> И даже после этого ничего не произойдёт. :) А всё потому что
> исходный файл будет в левом виде.
> man pwd_mkdb:
> ===
> The file must be in the correct format (see
> passwd(5)).
> ===
> Я даже это дело опробовал сейчас. Как и ожидалось, защита от дурака
> работает :)После этого и не должно ничего страшного произойти. Учитесь читать маны и понимать смысл сказанного.
>[оверквотинг удален]
>> исходный файл будет в левом виде.
>> man pwd_mkdb:
>> ===
>> The file must be in the correct format (see
>> passwd(5)).
>> ===
>> Я даже это дело опробовал сейчас. Как и ожидалось, защита от дурака
>> работает :)
> После этого и не должно ничего страшного произойти. Учитесь читать маны и
> понимать смысл сказанного.Учитесь читать сообщения и понимать смысл написанного: своим ответом вы подтвердили то, что я и написал. И смысл?
> А потом pwd_mkdb -p /etc/master.passwd
> Учитесь отращивать админское брюхо, молодой человек.Це только на фряхе.
А, помнится, на линуксе затирание /etc/passwd приводило к очень веселым последствиям.P.S.
Админское брюхо - это не интересно.
А вот очень удаленное выполнение команды:
"ee /etc/ipfw.conf ; kldload ipfw ; ipfw -f /etc/ipfw.conf; sysctl net.inet.ip.fw.enable=1"
куда интереснее.
Развивает наблюдательность и крепость нервов =)
> Це только на фряхе.
> А, помнится, на линуксе затирание /etc/passwd приводило к очень веселым последствиям.В линуксе же shadow.passwd(или как-то так) есть, не?
> P.S.
> Админское брюхо - это не интересно.
> А вот очень удаленное выполнение команды:
> "ee /etc/ipfw.conf ; kldload ipfw ; ipfw -f /etc/ipfw.conf; sysctl net.inet.ip.fw.enable=1"
> куда интереснее.
> Развивает наблюдательность и крепость нервов =)А тут в чём проблема? Первым правилом что-нибудь вроде "allow tcp from any to my_host ssh_port keep state"(синтаксис ipfw подзабыл уже) и никаких проблем.
>> Це только на фряхе.
>> А, помнится, на линуксе затирание /etc/passwd приводило к очень веселым последствиям.
> В линуксе же shadow.passwd(или как-то так) есть, не?Неа.
Только /etc/shadow, но это аналог master.passwd.
А данные о юзерах берутся из /etc/passwd.
Теперь вникаете в суть прикола?)>> P.S.
>> Админское брюхо - это не интересно.
>> А вот очень удаленное выполнение команды:
>> "ee /etc/ipfw.conf ; kldload ipfw ; ipfw -f /etc/ipfw.conf; sysctl net.inet.ip.fw.enable=1"
>> куда интереснее.
>> Развивает наблюдательность и крепость нервов =)
> А тут в чём проблема? Первым правилом что-нибудь вроде "allow tcp from
> any to my_host ssh_port keep state"(синтаксис ipfw подзабыл уже) и никаких
> проблем.Тогда надо 2 правило, from any to me и from me to any.
А суть в том, что в указанной команде применение правил фаерволла начинается сразу же после выхода из редактора.
Так что надо быть очень внимательным)
> Неа.
> Только /etc/shadow, но это аналог master.passwd.
> А данные о юзерах берутся из /etc/passwd.
> Теперь вникаете в суть прикола?)Да что вы говорите? А как же файлы(два) с расширением *.db? Или в линуксе и этого нет? Так что суть прикола по-прежнем сокрыта от меня.
> Тогда надо 2 правило, from any to me и from me to
> any.
> А суть в том, что в указанной команде применение правил фаерволла начинается
> сразу же после выхода из редактора.
> Так что надо быть очень внимательным)Зачем? ipfw прекрасно умеет отслеживать tcp-сессии. Почитайте маны на досуге, много нового откроете для себя.
ну, мунин - это не альтернатива нагиосу и исинга. последние два - это алертилки. мунин строит графики.
кокие алертики, к нагиосу легко прикручивается nagiosgrapher
я бы советовал связку, мониторинг работы, моргания и т.д. - нагиос, графики - мунин.
Интересно, насколько эта система тяжелее зеноса?
zenoss написан на жопе (zope), и не очень-то быстрый
Ну я про это и спрашиваю. Голый зеннос хавает 300 мег
про исингу ничего не скажу, но нагиос намного легче
zabbix не?
> zabbix не?Заббикс при всех его достоинствах - слишком много кушать для мониторинга. То есть, того компа, что выделили для этого, элементарно не хватило на ~40 серверов (2xP4 2.4GHz/512Mb).
С нагиосом - загрузка минимальна.
потому что по дефолту, система сохраняет все значения опрашиваемых параметров, для постройки графиков. если эту байду выключить (т.е. стать обыкновенной опрашивалкой), то нагрузка на sql уменьшится до нужд хранения только конфигурационных данных.p.s. спецы нагиоса объясните мне такое поведение плагина check_snmp_storage
http://s43.radikal.ru/i100/1010/ef/675b40bb850e.png
я вот никак не в восторге от этого)))) что мне теперь подгонять теперь в шаблонах везде "-R" и вручную подставлять процент под каждую файловую систему?
> p.s. спецы нагиоса объясните мне такое поведение плагина check_snmp_storageНе то чтобы я был "спецом нагиоса", но я бы начал с nagios -v <конфиг нагиоса>. Если где-то есть ошибка - данные не обновляются.
не видимо я плохо объяснил, данные снимаются как надо, nagios -v отрабатывает на отлично. покажу следующую картину,
картина на узле
prol ~ # df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/md0 9.2G 7.9G 932M 90% /
prol ~ # df /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md0 9621816 8179384 953660 90% /картина на мониторинге
kvm520-sm nagios # check_snmp_storage -H prol -C gJilIogg -w 90% -c 95% -m / -r
OK : /: 85%used(7988MB/9396MB) : < 90 % | /=7987MB;8456;8926;0;9396
kvm520-sm nagios # check_snmp_storage -H prol -C gJilIogg -R 6% -w 90% -c 95% -m / -r
WARNING : /: 90%used(7988MB/8833MB) : > 90 % | /=7987MB;7949;8390;0;8832-R 6% это чтобы подогнаться к ext3, для reiserfs - 5% , и этот -R нужно обязательно вводить чтобы получить значения которые соответствуют действительности, иначе получим немного обрезанные данные (без каких-то зарезервированных блоков для рута)
имхо это лишняя фича, и вводит в заблуждение новичков, когда они видят расхождение в значениях)))и сейчас осваиваю нагиос, наталкиваюсь на такие фокусы почти через раз:)
эээм, а агента на хост поставить и check_disk юзать никак?
к сожалению нельзя, нужно использовать только snmp, т.к. дефицит ресурсов.
хохох, это вы при дифиците запускаете на наблюдаемой машине snmpd??
подскажите мне другие варианты, будет интересно выслушать.
вообще по моим наблюдениям, snmpd отжирает больше памяти чем zabbix_agent (оба работают под одиинаковым количеством запросов), но использование snmpd обусловлено тем чтобы на всем оборудовании был один и тот же инструмент.
аргумент использования snmpd какой-то не очень. На сетевый девайсах - понятно, но вот на серверах лучше использовать агента конкретной системы мониторинга. Для Nagios - это nrpe
как-то математика не сходится:
(7.9G / 9.2G) * 100% = 85%\
и даже
(8179384 / 9621816) * 100% = 85%
ну никак не 90% %)
так что Nagios тут непричем.
> как-то математика не сходится:
> (7.9G / 9.2G) * 100% = 85%\
> и даже
> (8179384 / 9621816) * 100% = 85%
> ну никак не 90% %)
> так что Nagios тут непричем.погуглив узнал что есть такая штука как reserved block ? как оказалось, просто плугин не считает эти зарезервированые блоки, а df - считает. получается расхождение)))
так что вроде и причем, и не причем... просто имхо, подсчет блоков должен быть включен по умолчанию. опять же как я уже писало, разные фс при форматировании по разному определяют процент резервирования.
в ext3 это -m reserved-blocks-percentage ... The default percentage is 5%.
вот еще один момент, плугин check_snmp , запрашивает значение OID и выдает warn или crit если полученное значение !БОЛЬШЕ! (и только "больше") образца.
Вот, а мне к примеру надо отслеживать uptime и мне надо получать warn когда значение меньше.
check_snmp -H odion -C gJilIogg -o 1.3.6.1.2.1.1.3.0 -w 43200
SNMP WARNING - *292528060* | iso.3.6.1.2.1.1.3.0=292528060как мне указать, что варнинг должен вылазить, только когда полученное значение меньше задаваемого образца?
условий вобщем нехватает мне, или я еще ненашел:)
> check_snmp -H odion -C gJilIogg -o 1.3.6.1.2.1.1.3.0 -w 43200Если склероз мне не изменяет, там есть еще параметр "-с", для critical, указываете значение для срабатывания, которое вам надо для critical
> Если склероз мне не изменяет, там есть еще параметр "-с", для critical,
> указываете значение для срабатывания, которое вам надо для criticalнет не изменяет, "-с" конечно желательно указывать во всех проверках как второй порог, который говорит что настал совсем ахтунг... но деле не в этом, в моем случае это не решит, проблемы. вот смотрите:
аптайм машины - 80 дней. мне нужен одиночный алерт если вдруг аптайм окажется меньше 1 часа. и всё. я поставлю -w 3600 -с 1800, но это бессмысленно, плугин будет возвращать warn когда аптайм будет больше 3600 и crit когда больше 1800 но меньше 3600. вот как мне сделать чтоб warn был только когда значение меньше 3600 ?
unix way - модифицируй скрипт :)
> вот еще один момент, плугин check_snmp , запрашивает значение OID и выдает
> warn или crit если полученное значение !БОЛЬШЕ! (и только "больше") образца.
> Вот, а мне к примеру надо отслеживать uptime и мне надо получать
> warn когда значение меньше.
> check_snmp -H odion -C gJilIogg -o 1.3.6.1.2.1.1.3.0 -w 43200
> SNMP WARNING - *292528060* | iso.3.6.1.2.1.1.3.0=292528060
> как мне указать, что варнинг должен вылазить, только когда полученное значение меньше
> задаваемого образца?
> условий вобщем нехватает мне, или я еще ненашел:)товарищ! ну запусти ты check_snmp --help и воткни в пороги типа -w 1:10 и сразу придумаешь как тебе выполнить твою задачу
> товарищ! ну запусти ты check_snmp --help и воткни в пороги типа -w
> 1:10 и сразу придумаешь как тебе выполнить твою задачупробовал не работает((((
# check_snmp -H torre -C gJilIogg -o 1.3.6.1.2.1.1.3.0 -w 0:3600
SNMP WARNING - *232208713* | iso.3.6.1.2.1.1.3.0=232208713это как какая-то идиотская аксиома, аптайм выходит за диапазон, => warning.
если решения не удается найти действительно, то как крайний вариант - плагины можно писать самому. там bash или perl.
а если подумать и попробовать что-то типа
check_snmp -H torre -C gJilIogg -o 1.3.6.1.2.1.1.3.0 -w 3600:0вроде так, или -w 3600: (т.е. без нуля, но с двоеточием)
> а если подумать и попробовать что-то типа
> check_snmp -H torre -C gJilIogg -o 1.3.6.1.2.1.1.3.0 -w 3600:0
> вроде так, или -w 3600: (т.е. без
> нуля, но с двоеточием)-----------------
Да, двоеточие надо, а еще интервал можно указать -w 3600:4000
На одном из моих прежних мест работы (крупный хостер, более 1000 серверов в нескольких ДЦ + N-ное количество цисок), ходили легенды про то, как заббикс подавился такими объемами. Дело было до моего там появления, поэтому подробностей не знаю. Собственноручно поднимал там систему мониторинга на нагиосе (5 серверов мониторили хозяйство, шестой собирал и отображал сводные данные и мониторил остальные нагиосы) - этого вполне хватало, LA выше 7-8 не взлетал, и тормозов не наблюдалось. 2-ядерный Xeon, 4G RAM, nagios, apache2, FreeBSD. Может, заббикс был неудачно приготовлен, но нагиос и до сих пор там живет и пасется.
А каким образом это было сделано? Чтобы 5 серверов мониторили, а 1 собирал?
Единственное что приходит в голову это то что этот единственный сервер запускал на той стороне npre плагины... Или как это сделать в nagios?
да интересно послушать про реализацию.. в заббиксе это делается на раз-два через заббикс-прокси, наверняка такие же плюшки есть и в нагиосе
возможно что-то типа:
http://mathias-kettner.de/checkmk_livestatus.htmlили аналогичное?
Отвечу за него. В нагиосе есть несколько механизмов, nrpe самый плохой из них, т.к. приходится на каждую проверку запускать новый процесс. Есть merlin (советую посмотреть http://www.op5.org/op5media/op5.org/downloads/merlin-scenari... ) и есть Distributed Nagios Executor ( http://dnx.sourceforge.net/ ). Это NEB модули, которые работают в адресном пространстве нагиоса, поэтому у них нет дополнительных расходдов как в случае nrpe.Вообще очень странно, что на 1000 хостов автор использует несколько машин. У нас тоже более 1000 хостов, и справляются 2 виртуальных контейнера, один под сам нагиос, второй под базу для хранения всех результатов проверок.
> Вообще очень странно, что на 1000 хостов автор использует несколько машин.На каждом из этих хостов мониторилось весьма большое количество сервисов. Согласен, это некоторая избыточность, но очень не хотелось лишиться мониторинга, либо его актуальности - это больше политическое, чем техническое решение. А в подходящем железе недостатка не было. И конфигурилось оно централизованно (svn+puppet).
nagioser, padvo - Спасибо Большое!
Плюшка называется send_nsca. Есть среди плагинов. Хост-коллектор настраивается на мониторинг всего хозяйства (все, что мониторится, должно быть указано в конфиге). Все эти проверки на хосте-коллекторе определяются как пассивные. На остальных хостах - активные. Вот конфиг для этой штуки (пути фряшные, в линуксах будут другие, адаптируйте).# send_nsca command path
CMD="/usr/local/sbin/send_nsca"
# send_nsca config file
CFG="/usr/local/etc/nagios/send_nsca.cfg"
# where to send passive checks
PASSIVEHOST=<master_host> # Имя хоста-коллектора
# where to log send events
LOG="/opt/nagios/send_host_nsca.log"
# how often send events (per min)
OFTEN="6"
# mv log before send
TMPSEND="/tmp/passive_host_event.log.$$"
# log
TMPREC="/tmp/passive_host_event.log"А по поводу -R - Вы, похоже правы, у нас было некоторое количество линукс-машин с ext3, но диски мониторил самописный демон, а не этот плагин.
в том и незадача, при использовании nagios часто приходится прибегать каким то третьим инструментам, например jabber-уведомления, пришлось приделать через pl-скрипт, веб-морда для виндо-админов - nagiosql, графики - cacti или pnp4nagios
хочется пожелать icingа-девелоперам удачи в работе, чтобы они сделали прекрасный инструмент, где все это будет в одном месте:)
не. на самом деле не надо. нагиос - это конструктор. идея как раз в том, чтобы делать только то что нужно. если же требуется уже готовое со всеми возможностями, то используйте лучше заббикс или зеносс.
желательно чтоб детали конструктора находились хотя бы в одной коробке)))) а так любая система является по сути конструктором.
unix-way. Тут приходится выбирать - либо конструктор, из которого можно собрать всё что угодно, либо "энтерпрайз", немеряно жрущий ресурсов по умолчанию и подразумевающий "шаг влево - шаг вправо - расстрел". Каждый выбирает для себя более удобное.
Спасибо автору анонса! Поставил у себя - просто "песня души". Особенно порадовал мануал на сайте разработчиков - под фряху, по-крайней мере. Сотня хостов за какую-то пару часов :). С заббиксом как-то тяжелее оказалось - уж больно он на трафик прожорлив оказался. Посмотрю, сколько исинга/нагиос кушаеть.
