Пользователь
0,0
рейтинг
2 августа 2008 в 15:40

Администрирование → Munin — мониторинг сети это просто!


В жизни каждого системного администратора рано или поздно наступает момент, когда глаз и рук уже не хватает уследить за всеми серверами, то там, то там возникают какие-то проблемы, а для решения их очень хочется узнать что же было «до этого». И именно здесь на выручку приходят они — вел
икие и ужасные системы мониторинга. Долгое время я пользовался Nagios, и до сих пор, при всём удобстве, иначе как монстрообразным назвать не могу. В итоге реально использовались лишь 10% возможностей этой прекрасной системы. Всё изменилось, когда я наткнулся на Munin — прекрасное решение для мониторинга небольших сетей.

Сама система состоит из двух независимых частей: сервера (сам munin), устанавливается на одну машину, куда и будут собираться все данные, и небольшого демона munin-node, который устанавливается на машины, которые мы будем мониторить. Сам этот демон представляет собой небольшой Perl-скрипт, который слушает 4949 порт с помощью Net::Server. При своём запуске он просматривает плагины, установленные в /etc/munin/plugins и запоминает их имена. Раз в 5 минут сервер munin подключается ко всем нодам, получает информацию от всех плагинов и сохраняет себе в базы rrdtool. Таким образом, для работы Munin'а не нужен даже MySQL.

Плагины — самое вкусное что есть в Munin'е. Невероятная простота их реализации позволяет написать плагины для всего, что хотите в системе затратив минимум времени на чтение документации. Видимо это и объясняет то, что сравнительно молодая система уже обросла большим количеством готовых плагинов.
Фактически, каждый плагин — исполняемый файл, который на выходе должен выдать текущие значения параметров.
Проще всего разобрать это на простейшем примере.

Для руководства сети очень нравится когда вся «жизнедеятельность» сети представлена понятными графиками, позволяющими им быстро оценить происходящее. И первый же график, который меня попросили сделать был количеством людей, сейчас подключенных в Интернет.
В качестве NAS используется FreeBSD (MPD). Клиенты подключены по PPTP, так что количество существующих ng интерфейсов в точности соответствует количеству абонентов онлайн (благо mpd5 научился «подметать лишние интерфейсы). Другими словами мы можем получить требуемое значение командой
ifconfig | grep ^ng | wc -l

Всё. этого достаточно для реализации плагина. В данном случае для реализации плагина нам достаточно sh (хотя никто не запрещает для написания плагинов использовать bash/perl/ruby/что-вы-хотите-и-знаете).
Вот код самого плагина:

#!/bin/sh
#
# Плагин для мониторинга количества пользователей биллинга
#

if [ „$1“ = „config“ ]; then
    echo 'graph_title Billing users'
    echo 'graph_vlabel users'
    echo 'graph_noscale true'
    echo 'graph_category Billing'
    echo 'users.label users'
    echo 'graph_info This graph shows amount of users connected to Internet';
    echo 'users.info Users amount'
    exit 0
fi

echo -n „users.value “
echo `/sbin/ifconfig | /usr/bin/grep '\-->' | wc -l`


Таким образом мы видим, что единственный параметр обрабатываемый скриптом — магическое слово config. Именно его передает плагину munin при первом запросе. В ответ на него скрипт должен возвратить спецификации будущего графика для rrdtool. За полной документацией я отсылаю Вас к замечательному руководству по написанию плагинов для Munin, сейчас же я разберу только используемые мной параметры.

graph_title Billing users — просто заголовок графика. Обращаю Ваше внимание, что по крайней мере на FreeBSD, rrdtool некорректно работает с великим и могучим, так что приходится обходиться английским;
graph_vlabel users — по вертикальной оси откладываем значение параметра users;
graph_noscale true — запрещаем rrdtool масштабировать график. Это полезно для того чтобы по оси откладывались реальные значения (2000 пользователей вместо 2*103);
graph_category Billing — категория графика. Графики из одной категории будут сформированы на одной странице;
users.label users — название оси „users“. Оно должно быть достаточно коротким чтобы уместиться на графике;
users.info Users amount — описание оси;

Крайне приятным открытием для меня стало существование munin-node-win, что позволяет мониторить и Windows-сервера, кои, пусть в небольшом количестве, но присутствуют у меня.

И в завершение, пару слов, о том что собственно на выходе. Я думаю демо скажет лучше тысячи слов — на выходе у нас сгенерированный html без единого намёка на скрипты.

Полезные ссылки
muninexchange.projects.linpro.no — коллекция готовых плагинов для Munin.
Сравнение систем мониторинга сети — крайне информативная таблица в Википедии, позволяющая быстро оценить насколько Вам подходит та или иная система мониторинга.
linux-ru.blogspot.com/2007/02/munin.html — об установке Munin на русском.
munin.projects.linpro.no/wiki/HowToContactNagios — дружим Nagios и Munin
Илья Климов @xanf
карма
112,7
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (42)

  • –1
    thx
  • –1
    ссылку на демо поправьте.
    • 0
      у меня работает. http://munin.ping.uio.no/ - вроде все верно
      • 0
        Глюк. После обновления страницы все нормально.
  • 0
    Хорошая статья, попробуем. Действительно легкость написания плагинов очень привлекает.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      тоже им пользуюсь. но это скорее средство "поддержания сервисов на плаву"
  • 0
    Еще есть такая вещь как Zabbix
    Позволяет делать эскалацию мониторинга
    • 0
      Прекрасно знаю. Но ИМХО Zabbix - хоть и лучше Nagios'а, но все равно истинную силу показывает при мониторинге... ну... хотя бы 50-100 машин. Для меньшего количество это пушка против воробьёв
      • 0
        заббикс ставится за пять минут, плюс ещё по 5 минут на агентов.
    • 0
      слышал о нем пару не лестных отзывов, что дескать что нибудь у него сломается и приходится чинить.
      • 0
        хм… ниче не ломается, стоит уже год, мониторит всё, если что-то упало варнит на мыло, смс и пытается поднять.

        удобная мониторилка (большое поле по вертикали сервера, по горизонтали сервисы) если что-то упало клетка становится красной. очень наглядно.
  • 0
    У rrd-based вещей есть один недостаток: при резком и однократном всплеске, автоматический масштаб подравнивается под этот пик и обычные колебания просто не видны.

    p.s. искал как-то не слишком навороченную систему на 7-10 хостов, чтобы плагины/агенты можно было б на питоне писать, с первого взгляда увидел только сырой pymon и zenoss, который сходу не осилил... в итоге пока что munin работает.
    • 0
      echo 'graph_noscale true' насколько я помню помогает + upper_limit (они позволяют жестко задать верхний лимит. пики просто уйдут вверх)
      • 0
        Ээээм. ЕМНИП, это настройки самого rrd, плюс нужно иметь оценку верхнего порога. А в munin, насколько знаю, таких настроек нет.
  • 0
    Спасибо за инфу, запомним...
  • 0
    Действительно, нагио хоть и стоит у многих клиентов, однако не сказал бы что им часто пользуешься.
    Спасибо!
  • +1
    Я тоже использую, 10-15 серверов.
    Вот проблемка, с которой я столкнулся http://sharifulin.livejournal.com/27286.…
    И еще munin начинает нереально спамить, если что-то случилось.
    Я сделал "хитрый" скрипт отправки, который отправляет уведомление только в первый и последний раз.
    • 0
      Я юзаю купленный HP OpenView, тож проблема спама аналогичным образом решается. Там тож на событие можно скрипты перловские вешать. А для простых оповещений, написал простой скрипт, на том же перле, который пингует мои основные ноды и если пинг не проходит в течении минуты, шлет мне письмо на мыло (на мобилку в виде SMS, есть у меня такое мыло). Как поднялся нод, тоже, один SMS. http://213.87.17.33/check_node.gz - тут лежит, если интересно.
  • +1
    у нас нагиос мониторит около 300 серверов. нареканий нет. помимо стандартных плагинов полно самописных.
    плагины для нагиоса писать проще простого - любой исполняемый файл, имеющий на выходе stdout и код возврата в диапазоне от 0 до 3

    на мой взягляд Nagios - это система оповещений о проблемах, чем просто "монитор", именно поэтому один из его недостатков - отсутствие (нормальных) графиков

    PS
    нагиос тоже кстати не юзает БД
    • 0
      обьясните мне дураку, чем же это так круто «не использовать бд».
      • 0
        Думаю, что некоторым не хочется использовать бд лишь для мониторинга.
  • 0
    Я правильно понял что мониторить можно только сервера?
    Или свитчи по snmp тоже можно?
  • 0
    А почему всем так не нравится nagios? Под него плагины так же просто пишутся, хорошо масштабируемый. И графики в нем тоже прекрасно можно строить.
  • 0
    Использовал и Nagios и Zabbix.
    + Nagios есть плагины практически под все задачи
    + Мало требует ресурсов
    - Страшный интерфейс
    - Муторно писать конфиги для каждого сервера.

    Zabbix
    + Большая часть того что нужно идет в комплекте
    + Агенты могут передавать не только статус какого-то процесса (жив/мертв) но и вообще любую инфу. Можно мониторить например, количество активных соединений в nginx, количество запросов в секунду в mysql, загрузку диска и т.п.
    + Поддержка тимплейтов. Создаем тимплейт веб-сервер и подключаем мониторинг N парамеров. Затем для сервера1, сервера2, сервера3 устанавливаем, что нужно использовать это тимплейт. Очень сильно экономит время для настройки.
    - При большом количестве параметров неплохо грузит систему.
    • 0
      В nagios'е можно назначать серверам те же самые template'ы.
    • 0
      Не использовал Nagios, но при знакомсте с документацией сделал вывод, что он то как раз должен сильно нагружать систему при большом количестве стоящих на мониторинге узлов и опрашиваемых на них параметрах! Это видно хотя бы по тому, что для опроса каждого устройства он создает новый процесс.
    • 0
      мониторинг параметров весьма полезен, например удобно смотреть граффики снятые со smart или очередь почтовую.

      большое количество это сколько?
  • –1
    А в портах он есть? Что-тоя не нашел. whereis munin ничего не даёт.
    • 0
      Странно вы ищите :)

      /usr/ports# make search name="munin"
      Port: munin-main-1.2.5
      Path: /usr/ports/sysutils/munin-main
      Info: Collector part of Munin
      Maint: lupe@lupe-christoph.de
      B-deps: freetype2-2.3.5 gettext-0.16.1_3 gmake-3.81_2 libart_lgpl-2.3.19,1 libiconv-1.11_1 p5-Authen-SASL-2.10_1 p5-Date-Manip-5.44 p5-Digest-1.15 p5-Digest-HMAC-1.01 p5-Digest-MD5-2.36 p5-Digest-SHA1-2.11 p5-GSSAPI-0.24 p5-HTML-Template-2.9 p5-MIME-Base64-3.07 p5-Net-1.22,1 p5-PathTools-3.25 p5-Scalar-List-Utils-1.19,1 perl-5.8.8_1 pkg-config-0.22_1 png-1.2.22 rrdtool-1.2.23
      R-deps: freetype2-2.3.5 libart_lgpl-2.3.19,1 p5-Authen-SASL-2.10_1 p5-Date-Manip-5.44 p5-Digest-1.15 p5-Digest-HMAC-1.01 p5-Digest-MD5-2.36 p5-Digest-SHA1-2.11 p5-GSSAPI-0.24 p5-HTML-Template-2.9 p5-MIME-Base64-3.07 p5-Net-1.22,1 p5-PathTools-3.25 p5-Scalar-List-Utils-1.19,1 perl-5.8.8_1 pkg-config-0.22_1 png-1.2.22 rrdtool-1.2.23
      WWW: http://www.linpro.no/projects/munin/

      Port: munin-node-1.2.5_1
      Path: /usr/ports/sysutils/munin-node
      Info: Node-specific part of Munin
      Maint: lupe@lupe-christoph.de
      B-deps: gettext-0.16.1_3 gmake-3.81_2 libiconv-1.11_1 p5-IO-Multiplex-1.09 p5-Net-Server-0.97 perl-5.8.8_1
      R-deps: p5-IO-Multiplex-1.09 p5-Net-Server-0.97 perl-5.8.8_1
      WWW: http://www.linpro.no/projects/munin/
    • 0
      whereis ищет не в портах а в том что уже установлено у вас
      • 0
        bm@high[~]
        >whereis mpd4
        mpd4: /usr/ports/net/mpd4

        bm@high[~]
        >pkg_info | grep mpd4

        Как видите не только в том, что установлено, но и по ФС в том числе.
    • 0
      Потому что
      rs# whereis munin
      munin:
      rs# whereis munin-main
      munin-main: /usr/ports/sysutils/munin-main
      rs# whereis munin-node
      munin-node: /usr/ports/sysutils/munin-node

      whereis работает не так как вы ожидаете :)
      • 0
        Ну да. Только я же не знал изначально правильных названий пакетов.
        • +1
          юзайте locate :)
          • 0
            Гм. И то верно. =)
  • 0
    Интересна максимальная нагрузка, которую способная выдерживать данная система? В свое время делал обзор систем мониторинга, рассматривал Cacti, Nagios, Zabbix и Zenoss. Пришел к выводу, что все эти системы могут справляться с нагрузкой в 1000 узлов с 10 параметрами на каждом, но вот при большей нагрузке, у некоторых начинаются проблемы... и дальше зависит от того, насколько мощное у вас железо и как хорошо вы настроили системы. В общем такие решения не годятся для крупных компаний с десятками тысяч сетевых устройств. Кстати, на нашем российском рынке появляются игроки, способные решать такие проблемы, разрабатывающие собственные OSS-системы.
    • 0
      Странно как-то, а почему так мало ? Эти системы я, правда, не пробовал, однако у меня есть самописная, которая собирает, анализирует и хранит в RRD порядка 500K параметров с более чем тысячи единиц оборудования.
      Машина, на которой это работает, вроде не очень мощная, я бы даже сказал, средненькая по нынешним временам - dual-core AMD Opteron 2.4GHz, 2G памяти. А по вашим подсчетам получается, что проблемы начинаются на чуть ли не на порядок меньшем количестве параметров.
      • 0
        500K - это достаточно много, но есть несколько вопросов. По каким протоколам опрашиваются устройства и сколько времени занимает эта процедура? На чем написана ваша программа?
        • 0
          Сетевые устройства - в основном по SNMP, некоторые дополнительно по RSH. Сервисы на серверах опрашиваются с использованием нативных протоколов - RADIUS, POP3, SMTP, DNS, и т.д. Сколько занимает - ну, зависит от того, насколько у устройства мощный проц :-) Написана на Tcl.
  • 0
    Может вы подскажите,?
    никак не могу понять, как получать графики не стандартно (день, неделя, месяц, год), а, например, час-день-неделя-месяц, поскольку графики за год мне не особо нужны, а вот получить более подробную картинку хотелось бы.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.