В данной статье рассматривается такой инструмент мониторинга, как Munin. Странно, но поиск уверяет меня, что статьи о нем на Хабре еще не было. Этот инструмент существует под *NIX (Linux, xBSD, Solaris) и Windows и позволяет централизовано отслеживать и наглядно отображать состояние подшефных систем. Изначально используется для отрисовки графиков, но также его можно использовать как чистое средство для наблюдения. Большой плюс Munin — гибкость (все графики рисуются плагинами, активными на целевых системах, и никто не запрещает использовать только те плагины, которые нужны) и возможность с одного сервера собирать информацию о множестве других. Соответственно, нагрузка на наблюдаемом сервере минимальна. Интересно? Добро пожаловать под кат
Munin — достаточно не новая система, развившаяся на популярном среди администраторов средстве отрисовки графиков RRDTool. Напомню, что идеология RRDTool состоит в хранении данных по «карусельному» типу — при заполнении базы фиксированного размера RRDTool начинает затирать данные с хвоста базы (то есть со старых) к голове (к новым), что гарантирует потерю минимального количества полезных данных, но при этом позволяет базе не распухать до безумных размеров (как у HP OpenView или Zabbix). Обычно в базе RRDTool есть несколько каруселей — например «мгновенные данные» (хранятся неделю), среднее за 5 минут (генерируется на основе мгновенных данных, хранятся месяц) и средние за час (генерируются на основе 5минутных, хранятся год. Такая база весит всего несколько мегабайт, и в размерах никогда не меняется (если данных в базе нет, в хвосте карусели просто стоят нули, слоты в базе под данные создаются сразу все). Минус RRDTool в его же плюсе. Нужно очень внимательно расчитывать емкость базы, потому что отредактировать созданную базу уже невозможно, и вытащить данные с целью перенести в другую базу (аналог DUMP в SQL базах) — тоже. Кроме того, RRDTool отвечает только за хранение данных, а их ведь еще откуда-то надо брать… Изначально админы использовали для этого самописные скрипты «на чем печень возжелает», традиционно первые места занимали всесущий Bash и мозголомный Perl (в последнем даже присуствует расширение для работы с RRD, остальные языки вынуждены использовать «подпорки» в виде вызова rrdtool прямиком из командной строки). Скрипты у всех были разные, качество кода и оптимизация работы таких скриптов гуляла в широчайших пределах. Сам я, на самой заре своей админской карьеры, писал подобные скрипты, причем писал «в лоб», простенький скрипт на пяток параметров мог выполнятся несколько секунд. Разумеется, в случае, когда возникает потребность (в инструменте удобного рисования графиков) — возникает и инструмент. Именно таким инструментом стал проект Munin.
Munin состоит из двух раздельных частей. Первая — это сервер (собственно, munin) — он опрашивает клиентов, хранит базу и рисует графики. Вторая — клиент (munin-node). Соединение с клиентом всегда инициирует сервер (он запускается по cron). При запуске сервер читает конфиг со списком адресов клиентов, обращается к каждому клиенту (порт — 4949/tcp), получает список возможных параметров, после чего — по списку — значения параметров. Полученые данные загружаются в RRD-файлы (если таковых нет — сервер их создаст). Рисованием готовых графиков ведает отдельный процесс, который хоть и входит в пакет munin, но живет совершенно самостоятельной жизнью.
В отличае от сервера, клиент — это постоянно находящийся в памяти демон. Написан он, как и сервер, на чистом perl. К слову сказать, единственный способ авторизации — IP, с которого инициируется соединение. Шифрования там также никакого, так что светить демона не советую, firewall и внимательную настройку конфига никто не отменял. Интересный факт, но сам демон ничего не знает о системе, в которой находится. Данные, которые клиент отдает серверу, он получает от плагинов-программ, которые последовательно запускает. За счет этого оптимизируется нагрузка на сервер (всегда можно оставить только те плагины, которые нужны), и вместе с тем — уменьшается время простоя демона, который уже не должен мучительно выдумывать параметры, которых в данной конкретной системе отродясь не бывало.
Как я уже упомниал выше, munin состоит из двух пакетов. Ставятся они тривиально, но нужно быть готовым к тому, что munin (сервер) потащит за собой немалую гору пакетов, отвечающих за RRD и графику (GD). Если мониторить надо один сервер — надо ставить оба пакета (пример для debian):
В отличае от monit, munin не может выполнять никаких действий в системе (кроме сбора статистики), как следствие — его можно запускать сразу после установки. В Debian GNU/Linux и CentOS демон запускается сам:
Активация плагинов сделана также просто и незатейливо — в папке с настройками munin (в linux это /etc/munin, а во freebsd — /usr/local/etc/munin) есть папка plugins. Все плагины, присутствующие в папке на момент запуска munin-node считаются активными. Если присутствующий плагин по какой-то причине отказывается работать (например, плагин сбора данных о MySQL при остановленом сервисе mysqld) — node вернет 0 при попытке получения информации из плагина.
На самом деле, все доступные плагины лежат обычно в другом месте, а в эту папку сложены симлинки.
Вот пример:
Изначально с munin поставляется немалое количество плагинов (обращаю внимание — активны не все!), кроме того, есть сайты, где также выложены плагины. Кроме того, существует руководство по написанию плагинов самостоятельно, но эта тема уже заметно выходит за рамки статьи.
Некоторые плагины поддерживают аргументы вызова. Вот яркий пример:
Реальные файл плагина
А вот что лежит в конфигурационной директории:
Без аргументов подобные плагины вызывать бесполезно — они не будут понимать, чего от них хотят.
Некоторые плагины поддерживают дополнительные настройки. Например, для плагина, собирающего информацию о MySQL можно задать логин и пароль для входа на сервер. Подобные настройки munin хранит в файле {confdir}/plugin-conf.d/munin-node.
Файл довольно подробно прокомментирован, но я, на всякий случай, приведу тут пару примеров:
Как можно убедится из примера выше, синтаксис файла очень несложный.
Сворачиваем растекание мыслью по древу. Теперь — четкие и понятные пошаговые инструкции.
Установка пакетов производится средствами ОС, собирать их из SRC не советую. Рассмотрим ситуацию, когда наблюдатель и наблюдаемый — физически одна машина.
Для начала настроим клиент:
Изменение конфига или списка плагинов требует перезапуска демона. При изменении списка плагинов нужно именно перезапускать демона, kill -HUP в данной ситуации не поможет.
Проверяем работу демона:
Командной list мы получили список активных плагинов, командой fetch — получили данные из одного плагина. Демон мониторинга ведет себя точно также, что позволяет с высокой степенью достоверности убедится в правильности работы клиента-нода.
Теперь переходим к серверу. В отличае от клиента (нода) — сервер не существует как процесс, он запускается только в моменты получения данных и рисования графиков (и то не всегда, этот вопрос будет рассмотрен ниже)
В списке процессов выглядит это вот так:
Настройки демона находятся в файле {config}/munin.conf
Он также очень подробно откомментирван, и ниже я приведу минимальный работоспособный пример.
Указаных выше настроек вполне хватит для нормальной работы. Более подробно эти настройки указаны в документации, но ждать многого от munin не надо — это полезный, но очень простой и ограниченый инструмент.
UPD: По заявкам трудящихся добавлены картинки уже установленого munin
Список хостов в наблюдении:
Примеры графиков:
Что?
Munin — достаточно не новая система, развившаяся на популярном среди администраторов средстве отрисовки графиков RRDTool. Напомню, что идеология RRDTool состоит в хранении данных по «карусельному» типу — при заполнении базы фиксированного размера RRDTool начинает затирать данные с хвоста базы (то есть со старых) к голове (к новым), что гарантирует потерю минимального количества полезных данных, но при этом позволяет базе не распухать до безумных размеров (как у HP OpenView или Zabbix). Обычно в базе RRDTool есть несколько каруселей — например «мгновенные данные» (хранятся неделю), среднее за 5 минут (генерируется на основе мгновенных данных, хранятся месяц) и средние за час (генерируются на основе 5минутных, хранятся год. Такая база весит всего несколько мегабайт, и в размерах никогда не меняется (если данных в базе нет, в хвосте карусели просто стоят нули, слоты в базе под данные создаются сразу все). Минус RRDTool в его же плюсе. Нужно очень внимательно расчитывать емкость базы, потому что отредактировать созданную базу уже невозможно, и вытащить данные с целью перенести в другую базу (аналог DUMP в SQL базах) — тоже. Кроме того, RRDTool отвечает только за хранение данных, а их ведь еще откуда-то надо брать… Изначально админы использовали для этого самописные скрипты «на чем печень возжелает», традиционно первые места занимали всесущий Bash и мозголомный Perl (в последнем даже присуствует расширение для работы с RRD, остальные языки вынуждены использовать «подпорки» в виде вызова rrdtool прямиком из командной строки). Скрипты у всех были разные, качество кода и оптимизация работы таких скриптов гуляла в широчайших пределах. Сам я, на самой заре своей админской карьеры, писал подобные скрипты, причем писал «в лоб», простенький скрипт на пяток параметров мог выполнятся несколько секунд. Разумеется, в случае, когда возникает потребность (в инструменте удобного рисования графиков) — возникает и инструмент. Именно таким инструментом стал проект Munin.
Обзор и архитектура
Munin состоит из двух раздельных частей. Первая — это сервер (собственно, munin) — он опрашивает клиентов, хранит базу и рисует графики. Вторая — клиент (munin-node). Соединение с клиентом всегда инициирует сервер (он запускается по cron). При запуске сервер читает конфиг со списком адресов клиентов, обращается к каждому клиенту (порт — 4949/tcp), получает список возможных параметров, после чего — по списку — значения параметров. Полученые данные загружаются в RRD-файлы (если таковых нет — сервер их создаст). Рисованием готовых графиков ведает отдельный процесс, который хоть и входит в пакет munin, но живет совершенно самостоятельной жизнью.
В отличае от сервера, клиент — это постоянно находящийся в памяти демон. Написан он, как и сервер, на чистом perl. К слову сказать, единственный способ авторизации — IP, с которого инициируется соединение. Шифрования там также никакого, так что светить демона не советую, firewall и внимательную настройку конфига никто не отменял. Интересный факт, но сам демон ничего не знает о системе, в которой находится. Данные, которые клиент отдает серверу, он получает от плагинов-программ, которые последовательно запускает. За счет этого оптимизируется нагрузка на сервер (всегда можно оставить только те плагины, которые нужны), и вместе с тем — уменьшается время простоя демона, который уже не должен мучительно выдумывать параметры, которых в данной конкретной системе отродясь не бывало.
Как
Установка и диагностика
Как я уже упомниал выше, munin состоит из двух пакетов. Ставятся они тривиально, но нужно быть готовым к тому, что munin (сервер) потащит за собой немалую гору пакетов, отвечающих за RRD и графику (GD). Если мониторить надо один сервер — надо ставить оба пакета (пример для debian):
apt-get install munin munin-node
....
В отличае от monit, munin не может выполнять никаких действий в системе (кроме сбора статистики), как следствие — его можно запускать сразу после установки. В Debian GNU/Linux и CentOS демон запускается сам:
lab:~# ps ax | grep muni
16139 ? Ss 0:00 /usr/sbin/munin-node
Активация плагинов сделана также просто и незатейливо — в папке с настройками munin (в linux это /etc/munin, а во freebsd — /usr/local/etc/munin) есть папка plugins. Все плагины, присутствующие в папке на момент запуска munin-node считаются активными. Если присутствующий плагин по какой-то причине отказывается работать (например, плагин сбора данных о MySQL при остановленом сервисе mysqld) — node вернет 0 при попытке получения информации из плагина.
На самом деле, все доступные плагины лежат обычно в другом месте, а в эту папку сложены симлинки.
Вот пример:
lab:~# ls -al /etc/munin/plugins/
total 2
drwxr-xr-x 2 root root 1024 2009-06-21 15:31 .
drwxr-xr-x 5 root root 1024 2010-02-11 23:35 ..
lrwxrwxrwx 1 root root 29 2009-05-19 16:39 acpi -> /usr/share/munin/plugins/acpi
lrwxrwxrwx 1 root root 28 2009-03-22 22:51 cpu -> /usr/share/munin/plugins/cpu
lrwxrwxrwx 1 root root 27 2009-03-22 22:51 df -> /usr/share/munin/plugins/df
lrwxrwxrwx 1 root root 33 2009-03-22 22:51 df_inode -> /usr/share/munin/plugins/df_inode
...
Изначально с munin поставляется немалое количество плагинов (обращаю внимание — активны не все!), кроме того, есть сайты, где также выложены плагины. Кроме того, существует руководство по написанию плагинов самостоятельно, но эта тема уже заметно выходит за рамки статьи.
Некоторые плагины поддерживают аргументы вызова. Вот яркий пример:
Реальные файл плагина
-rwxr-xr-x 1 root root 4775 2009-11-25 13:38 if_
-rwxr-xr-x 1 root root 3164 2009-11-25 13:38 if_err_
А вот что лежит в конфигурационной директории:
lab:~# ls -al /etc/munin/plugins/ | grep if
lrwxrwxrwx 1 root root 32 2009-03-22 22:51 if_err_eth0 -> /usr/share/munin/plugins/if_err_
lrwxrwxrwx 1 root root 32 2009-03-22 22:51 if_err_eth1 -> /usr/share/munin/plugins/if_err_
lrwxrwxrwx 1 root root 28 2009-03-22 22:51 if_eth0 -> /usr/share/munin/plugins/if_
lrwxrwxrwx 1 root root 28 2009-03-22 22:51 if_eth1 -> /usr/share/munin/plugins/if_
lrwxrwxrwx 1 root root 28 2009-06-21 15:31 if_tun0 -> /usr/share/munin/plugins/if_
Без аргументов подобные плагины вызывать бесполезно — они не будут понимать, чего от них хотят.
Некоторые плагины поддерживают дополнительные настройки. Например, для плагина, собирающего информацию о MySQL можно задать логин и пароль для входа на сервер. Подобные настройки munin хранит в файле {confdir}/plugin-conf.d/munin-node.
Файл довольно подробно прокомментирован, но я, на всякий случай, приведу тут пару примеров:
#информация для плагина APT
[apt]
#запускать от имени root. В противном случае APT не запускается
user root
#информация для всех плагинов множества smart_, эти плагины вызываются по принципу smart_{DISK}
[smart_*]
#опять же, только root сможет прочитать параметры из smartctl
user root
#информация для плагина postgres_queries, база mngsearch
[postgres_queries_mngsearch]
#env.{имя} у каждого плагина могут быть своими. Подробно надо смотреть в source-коде плагина
#в данном примере мы задаем имя пользователя и пароль для получения данных о работе базы mngsearch
env.PGUSER mngsearch
env.PGPASSWORD Yn2ajPV4f6V5rzqj
Как можно убедится из примера выше, синтаксис файла очень несложный.
пошаговые инструкции
Сворачиваем растекание мыслью по древу. Теперь — четкие и понятные пошаговые инструкции.
Установка пакетов производится средствами ОС, собирать их из SRC не советую. Рассмотрим ситуацию, когда наблюдатель и наблюдаемый — физически одна машина.
Для начала настроим клиент:
vi /etc/munin/munin-node.conf
...
log_level 4
#"говорливость" munin в журнале. 10 - режим отладки, 1 - полная тишина
log_file /var/log/munin/munin-node.log
#путь к журналу. Должен уже существовать
pid_file /var/run/munin/munin-node.pid
#pid-file, менять без необходимости не советую
background 1
#режим демона. Для отладки ставим 0 - и нод будет вечно висеть на консоли
setseid 1
user root
group root
#имя владельца процесса. Если это НЕ root, у него должны быть права на получение ID каждого имени пользователя, от имени которых запускается плагин проверки
#лучше пусть root и остается
setsid yes
#выставлять ID пользователя для каждого плагина. Трогать не советую
allow ^127\.0\.0\.1$
#с какого IP придет запрос сервера. В нашем случае - 127.0.0.1
#обращаю ваше внимание на то, что это не просто числа, а регулярное выражение (RegExp).
host 127.0.0.1
#к какому IP привязывать демон. В данном примере - к 127.0.0.1
port 4949
#соовтвественно, порт.
Изменение конфига или списка плагинов требует перезапуска демона. При изменении списка плагинов нужно именно перезапускать демона, kill -HUP в данной ситуации не поможет.
Проверяем работу демона:
lab:/etc/munin# telnet 127.0.0.1 4949
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
# munin node at lab.local.logan
list
open_inodes ip_127.0.0.1 postgres_queries_mngsearch irqstats
if_eth0 squid_cache sensors_temp df tor_connections swap
load cpu df_inode smart_hda forks iostat sensors_fan open_files
memory postgres_queries_netams exim_mailqueue vmstat sensors_volt
if_err_eth0 entropy processes acpi interrupts mysql_bytes if_tun0 if_err_eth1
if_eth1 tor_traffic exim_mailstats
fetch ip_127.0.0.1
in.value 83599135
out.value 83599135
.
quit
Connection closed by foreign host.
Командной list мы получили список активных плагинов, командой fetch — получили данные из одного плагина. Демон мониторинга ведет себя точно также, что позволяет с высокой степенью достоверности убедится в правильности работы клиента-нода.
Теперь переходим к серверу. В отличае от клиента (нода) — сервер не существует как процесс, он запускается только в моменты получения данных и рисования графиков (и то не всегда, этот вопрос будет рассмотрен ниже)
В списке процессов выглядит это вот так:
lab:~# ps ax | grep muni
16139 ? Ss 0:00 /usr/sbin/munin-node
17841 ? Ss 0:00 /bin/sh -c if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi
17842 ? S 0:00 /bin/sh /usr/bin/munin-cron
17843 ? S 0:00 /usr/bin/perl -w /usr/share/munin/munin-update
17846 ? S 0:00 /usr/share/munin/munin-update [r1sz.zooclub.ru]
17847 ? S 0:00 /usr/share/munin/munin-update [web1.zooclub.ru]
17848 ? S 0:00 /usr/share/munin/munin-update [monitor-01.infobox.ru]
17849 ? S 0:00 /usr/share/munin/munin-update [stat.kpp.ru]
17851 ? S 0:00 /usr/share/munin/munin-update [ro2-h.local]
17852 ? S 0:00 /usr/share/munin/munin-update [ro1-h.local]
17853 ? S 0:00 /usr/sbin/munin-node
17859 ? Rs 0:00 /usr/bin/perl /etc/munin/plugins/postgres_queries_mngsearch config
Настройки демона находятся в файле {config}/munin.conf
Он также очень подробно откомментирван, и ниже я приведу минимальный работоспособный пример.
dbdir /home/db/monitor
#место, где хранятся RRD. Путь должен существовать, а rrd демон создаст сам
htmldir /home/www/mon
#куда выкладывать готовые графики
logdir /var/log/munin
#где лежат логи
rundir /var/run/munin
#Описания серверов
[lab.local]
address 127.0.0.1
use_node_name yes
#эта директива нужна, на страничке с графиками отображалось имя узла, а не его адрес.
[midori.local]
#другой сервер, в той же группе
address 10.9.8.7
use_node_name yes
[web2.zooclub.ru]
#сервер в другой группе
address 77.221.150.98
use_node_name yes
contact.logan.command mail -s "Munin notification" logan@mydomain.my
#слать сообщения об ошибках. Информацию об ошибке сервер принимает от клиента. Изменение статуса (ОК<->ОШИБКА) будет сопровождатся письмом
#graph_strategy cgi
#можно использовать CGI для отрисовки графиков вместо отрисовки по крону. Это уменьшает нагрузку на сервер, если графики смотрят редко.
#Если графики смотрят часто (или много народу) - вы уложите сервер.
Указаных выше настроек вполне хватит для нормальной работы. Более подробно эти настройки указаны в документации, но ждать многого от munin не надо — это полезный, но очень простой и ограниченый инструмент.
UPD: По заявкам трудящихся добавлены картинки уже установленого munin
Список хостов в наблюдении:
Примеры графиков:
