четверг, 15 февраля 2007 г.

Мониторинг сервера и клиентов с помощью Munin.

Munin - это приложение для мониторинга серверов и обычных клиентских компьютеров под управлением Linux, написанное на языке Perl. Программа создает вывод изменений характеристик системы в виде графиков, встроенных в html страничку. По умолчанию осуществляется мониторинг использования файловой системы, памяти, процессора, активности сетевых служб и др. В принципе, вам должно этого хватить. Если же нужно отслеживать какие-нибудь специфические параметры, то можно добавить дополнительные плагины из уже созданных или написать самому.

В состав Munin входят пакеты как для сервера (munin), так и для клиентов (munin-node). Серверную часть нужно устанавливать только на самом сервере, клиентскую, как на сервере (если вы хотите анализировать и его), так и на всех клиентских машинах.

Здесь я опишу установку в Kubuntu Dapper Drake. Но, так как при написании я использовал материалы статей, описывающих установку в Debian, - считаю, что приведенное ниже годится для всех Debian-производных дистрибутивов. В конце приведена ссылка на статью, описывающую установку в SLES 10. Установив из RPM-пакетов, настраивать можно так же, как описано здесь.

Настройка Munin сервера.

Установка:
$ sudo apt-get install munin munin-node

Конфигурация:

Конфигурация munin сервера осуществляется редактированием конфигурационного файла /etc/munin/munin.conf.
Если вы осуществляете мониторинг лишь одной машины (самого сервера), то менять ничего не нужно. Если же есть клиентские машины - информацию о них нужно внести в этот файл.

$sudo vi /etc/munin/munin.conf

и найти секцию

# a simple host tree
[localhost.localdomain]
address 127.0.0.1
use_node_name yes

после этого добавляем клиентскую машину(ы);

[test.skku.ac.kr]
address 172.30.5.129
use_node_name yes

Замените test.skku.ac.kr и 172.30.5.129 на имя и IP клиентского компьютера соответственно.

Настройка munin клиента.

Установка:

$ sudo apt-get install munin-node

В результате установки будет создана директория /etc/munin, содержащая:

munin-node.conf - конфигурационный файл клиента

plugin-conf.d/munin-node - конфигурационный файл для настройки плагинов клиента

plugins - папка, в которой находятся символьные ссылки к плагинам в /usr/share/munin/plugins

Конфигурация:

Открываем файл munin-node.conf

$sudo vi /etc/munin/munin-node.conf

и добавляем:

полное имя клиентской машины

#host_name localhost.localdomain

host_name test.skku.ac.kr


и после allow ^127\.0\.0\.1$ записываем IP-адрес сервера, таким образом разрешая с него доступ на клиентскую машину

allow ^127\.0\.0\.1$

allow ^10\.52\.31\.41$

(можно задавать несколько серверов)

По умолчанию будут запускаться плагины, ссылки на которые находятся в директории /etc/munin/plugins. Это:

cpu entropy forks if_eth0 iostat memory mysql_slowqueries open_files processes df exim_mailqueue if_err_eth0 if_eth1 irqstats mysql_bytes mysql_threads open_inodes swap df_inode exim_mailstats if_err_eth1 interrupts load mysql_queries netstat postfix_mailvolume vmstat

Если же вы хотите добавить другие, нужно редактировать файл /etc/munin/plugin-conf.d/munin-node, где надо указать плагин, задание, пользователя и группу по аналогии с уже приведенными записями.

После этого нужно перезапустить munin клиент:

$sudo /etc/init.d/munin-node restart

и запустить следующее на сервере:

$sudo /usr/share/munin/munin-update --force-root

Munin задаст задание cron в файле /etc/cron.d/munin, который в свою очередь запустит /usr/bin/munin-cron.

Запуск и работа Munin.

Для того, чтобы проверить работу Munin на сервере в браузере, набираем:

http://ipaddress/munin

В случае возникновения каких либо проблем проверьте логи в папке /var/log/munin/
для сервера:
munin-node.log - отображает данные о состоявшихся соединениях
munin-graph.log - отображает данные о сервисах, для которых были построены графики
munin-html.log - информация о сгенерированном коде html.
для клиента:
munin-node.log - отображает данные о состоявшихся соединениях

Если же проблем не возникло, то в окне браузера должно появиться примерно следующее:



Т.е. я буду осуществлять мониторинг своей локальной машины (в данном случае она выступает и сервером) и удаленного клиента в домене skku.ac.kr.

Список параметров, для которых будут строиться графики, приведен на следующем рисунке:



Ну и сами результаты мониторинга (на следующий день после установки)






Ссылки:
http://munin.projects.linpro.no/
http://www.debianhelp.co.uk/munin.htm
http://www.debian-administration.org/articles/229
http://www.howtoforge.com/server_monitoring_monit_munin
http://www.novell.com/coolsolutions/feature/17913.html#9

26 коммент.:

Эргил Осин комментирует...

Коллега, а что это за баден-баден у вас в начале?
sudo sudo

serhiy комментирует...

Это для супер-супер привилегированного пользователя!:). Спасибо, что заметили. Уже исправил.

Drongo US комментирует...

Да ето все хорошо... но почему никто не пишет как настроить мунин более глубоко.
Например для снятия инфи с виндових машин... для алертов ну ...
Ето я могу и в мануале найти.

Короче САКС.

serhiy комментирует...

Да. Читайте мануалы. Кто же лучше напишет о программе, чем сами разработчики. А не нашли о виндовых машинах и алертах, так это не ко мне. Можете персонально написать разработчику. И вообще. А это возможно, установить munin-клиент на виндовс?

sergicus комментирует...

Большая просьба для знатоков настройки munin помочь настроить отображение деятельности плагинов squid . На опеннете никто помочь не может - описание проблемы здесь http://www.opennet.ru/openforum/vsluhforumID1/80911.html.

Увы нет информации по настройки сквид плагинов - рыл везде - ничего

Анонимный комментирует...

нет ничего не реального =)
тем более есть munin-node-win

Unknown комментирует...

Сразу после установки на локальную машину (fedora 7) из репозиториев, перестали обновляться графики. Т.е. увидел только первое значение, спустя 12 часов новых значений не добавилось. Логи ничего подозрительного не показали (каждые 5 минут соединение). Никто не сталкивался?

Murz комментирует...

$sudo /usr/share/munin/munin-update --force-root

при обычном запуске от рута munin ругается, что его не стоит запускать с правами рута. А параметр force-root ему говорит это игнорировать. Может быть правильней всё же его запускать от какого-либо пользователя, а не рута?

Murz комментирует...

Мне кажется система отображения данных у munin не очень подходящая для мониторинга. Насколько я понимаю, он каждые 5 минут генерит html-ки и png-картинки для графиков. Но ведь обычно в систему мониторинга поглядывают только изредка, чтобы проверить что всё впорядке или всё плохо.
Так зачем же каждые 5 минут тратить ресурсы сервера чтобы рисовать картинки? Мне кажется более правильно генерить графики на момент обращения к ним, а всё остальное время только накапливать информацию в базе...

Анонимный комментирует...

munin подкупает своей простотой, и "модульностью". Например чтобы написать свой плагин, надо всего-то капельку разбираться в скриптинге на shell.

slon комментирует...

2 Murz
Генерацию картинок можно делать так часто насколько вам нужно.

Создать скрипт для генерации по запросу несложно.

Murz комментирует...

Я понимаю что с помощью скриптов можно сделать что угодно, но большая часть пользователей обычно пользуется настройками по-умолчанию и не горит желанием что-то дописывать и переписывать. Как мне кажется, система мониторинга должна загружать сервер как можно меньше, да и большинство народу используют мониторинг чтобы заглянуть всё ли в порядке раза 2-3 в неделю. Поэтому смысла нагружать процессор генерацией картинок каждый раз, по-моему, нет.
Поэтому правильнее бы сделать чтобы они генерировались по запросу (тем более они генеряться быстро, а не часами) в настройках по-умолчанию, ну а для параноиков - оставить режим постоянного обновления графиков.

Анонимный комментирует...

>...но большая часть пользователей...
Не пользовательское это занятие, админское :) Для пользователей предусмотрены графические средства мониторинга (что-то в гноме попадалось). Munin целиком соответствует unix-way, за это его и любят. А "теоретическими недостатками" (типа: "Поэтому смысла нагружать процессор генерацией картинок каждый раз, по-моему, нет.
Поэтому правильнее бы...") можно пренебречь в пользу практичности. Буду рад (и это не сарказм), если вы (to Murz) порекомендуете систему мониторинга с меньшем количеством недостатков, но и не меньшей гибкостью (Например: мониторинг "примонтированности" раздела я написал за 40 минут).

Murz комментирует...

kirillrst, под "пользователей" я не имел ввиду "ламеров" и "блондино", а имелись в виду все пользователи программы Munin.
Админы тоже не все грамотные и умеющие писать скрипты к сожалению, да и те кто умеют - по большей части ленивые ;)

А про модули, проверяющие что-то - это писать одинаково легко для большинства систем мониторинга: достаточно написать скрипт или исполняемый файл на любом языке (хоть на php хоть на shell хоть на с), который будет при исполнении возвращать 1 или несколько цифр как результат проверки.
И стравливаешь этот файл мониторингу, который его с определенным интервалом дрючит и складывает результаты в базу.

Я писал такие модули и для Webminstats в Webmin и для Zabbix (который использую сейчас) и для Pandora и для munin уже тоже немного наковырял модулей под свои нужды пока тестирую.

Раньше я пытался свою систему мониторинга написать, но окончилось всё недоделанным выкидышем школьника ;)

А теперь ищу себе идеал, пока прошёл путь:
Самописные -> mon Service Monitoring Daemon -> Nagios -> Webminstats -> снова самописные -> Pandora FMS - Zabbix -> Monit -> Munin -> Zabbix и наиболее подходящим для моих нужд остается Zabbix.

Анонимный комментирует...

Солидный опыт,Murz ! А чем Zabbix лучше munin? И сколько вы пользуетесь тем и другим? Я не докапываюсь, просто munin меня тоже не всем устраивает.

Murz комментирует...

kirillrst, ну у Zabbix немного другой подход к сбору и хранению данных. Работает всё также: сервер, который собирает инфу и агенты, которые ему её поставляют.

Все данные сервер сваливает в базу данных (которая группируется и чистится со временем). Восновном там идёт упор не на визуальное представление, а на уведомление о проблемах. Т.е. есть сервер, есть какой-то параметр. Потом настраиваются события, например что параметр вдруг стал резко расти или наоборот перестал или стал выше чем разрешено или перестали данные приходить уже больше чем критичный интервал. В комплекте уже идут основные события (память кончается, место на диске, изменился md5-хеш файла /etc/passwd и т.д., подменили бинарник ssh).

На основе событий можно делать триггеры и уведомления (как на наступление 1 события, так и совокупность нескольких /например, кончился винт и освоободиласть память/, так и на какие-то последовательности /5 раз в сутки кол-во процессов httpd превышало 20/).
Также гибкая настройка пользователей (например создание групп, разных типов сообщений о проблемах (например, в рабочие дни с 9 до 6 - по SMS, в нерабочие - по мылу и в jabber).
Соответственно, можно удалять/править родные, добавлять свои источники, события, уведомления и всё что угодно.

Но в итоге система получается громоздкая и перегруженная: новичку придётся долго вкуривать что там к чему - куча закладок, параметров, кнопок, групп, цифер и т.д. Также ресурсов требуется ей для этого побольше (восновном для сохранения в базу и на интерфейс отображения данных, т.к. для сбора там всё на C++ написано и довольно шустро бегает). Плюс в комплекте у Zabbix идёт мониторинг всех узких мест системы, которые жалко удалять, а сам бы с нуля настраивать поленился бы ;) В итоге проверяются сотни параметров, в которых можно запутаться. Впринципе, если все эти проверяемые параметры добавить в Munin - то он тоже будет также тормозить и станет непонятным (сотни графиков непойми чего).

Но, как я уже говорил, можно всё стандартное поудалять и пользовать только то что нужно.

Радует ещё и то, что на основе любых данных (история параметра, совокупности параметров, смена триггера вкл-выкл) можно построить график как по одному параметру, так и сравнить несколько совершенно разных (например, объем свободной памяти и кол-во процессов apache на одном графике). И посмотреть всё это можно за любой период времени (пока не почистились данные из бд, интервалы настраиваются, по-умолчанию - год): т.е. пришло например письмо что сайт 32 дня назад тормозил 30 минут - ты раз, построил подробный ежеминутный график за эти пол часа, по данным и посмотрел как всё было на самом деле и нашёл причину. Меня уже много раз это выручало!

А в системах, основанных на графиках rrd, это невозможно, т.к. из инфы остаются только графики за последние интервалы и всё. Ну или логи писать и руками парсить.

Вобщем у Zabbix всё отлично кроме сложности освоения и громоздкости, поэтому его просто лениво настраивать на каждой новой машине, на которой хочется простого: когда вдруг начались проблемы - посмотреть несколько параметров:
- график загрузки сетевого интерфейса
- занятость памяти, проца
- история каких-то особых проверок (например, уровень роста строк в mysql-таблице комментариев сайта, чтобы засечь каммент-спам)

Вот для этого и ищу какую-нибудь лёгкую альтернативу и набрёл на munin.

Unknown комментирует...

Murz, благодарю за развернутый ответ. Убедили, чуть освобожусь - займусь освоением Zabbix.

Murz комментирует...

Ну а вообще в плане мониторинга я никак не могу добиться мониторинга следующего... Если кто поможет или подскажет - буду премного благодарен, можно даже в денежном эквиваленте!

Вобщем, ситуация такая:
Есть сервер с apache2, на котором висит например 100 сайтов. Сайты по большей части чужие и на разных CMS. Среди них:

- Говносайты (обычно домашние странички каких-нибудь фирм: минимальный функционал - о компании, каталог продукции, прайс-лист, бывает даже без БД, посещают 1-2 человека в день)

- Сайты-решето (установлена какая-то CMS или скрипты, сделан форум или гостевуха, в итоге на сайте постоянно сруться в камментах боты, плюс ещё спам рассылают через дырявые скрипты)

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

Задача в следующем: сервер работал, никого не трогал, вдруг начались проблемы:
- IP забанили за спам по e-mail
- Сайт забанили в поисковиках за спам в камментах
- Сервер стал жудко тормозить
- Стали появляться висящие httpd-процессы
- ну и всякие разные другие проблемы.

В результате для предвидения проблем хотелось бы в наглядном виде мониторить (желательно на 1 странице, чтобы зашёл-глянул-спишьспокойно) следующие параметры, например по дням:
- кол-во обращений к каждому virtialhost в сравнении с остальными и история изменений (засечь резкое увеличение интересов спам-ботов к сайту)
- кол-во post-запросов к каждому virtualhost (засечь резкое увеличение камментов
- кол-во отосланных писем от каждого virtualhost через php (рассылка спама через дырявую форму)
- кол-во записей error.log по каждому virtualhost
- время min,max,avg, потраченное на выполнение php-скриптов этого virtualhost (для выявления криворуких кодеров)
- кол-во чтения-записей в mysql-базу и трафик до неё по виртуалхостам (или логинам).
- ещё какие-то ручные проверки.

Всё это можно написать ручками, как и интерфейс их отображения на одной страничке. Но хочется что-то уже готовое и универсальное, чтобы просто дописать недостающие модули.

И я удивлен что до сих пор ещё ничего не придумали такого (или я плохо гуглил), ситуация ведь стандартная для любого сервера хостинга!

Flaresun комментирует...

> Murz wrote:
> Так зачем же каждые 5 минут тратить
> ресурсы сервера чтобы рисовать картинки?


Не забывайте, что munin может показывать не только html-странички, но и работать как cgi и fastcgi. В жтом случае один из пунктов настройки является
> Remove munin-graph from munin-cron
т.е. будет просто созранятся статистика, на картинки процессор зря расходоваться не будет.

calibra комментирует...

world of warcraft мировая игра которая получила популярность во всем мире.

Анонимный комментирует...

О а я тут видел хороший сайт по этой статье Хакер сайт

олег комментирует...

Полезная статья

иван комментирует...

Нужная информация

Анонимный комментирует...

This can be flight simulator version FS2002, FS2004 or the latest version of Flight Simulator, FSX.
You must know the different points that you want from a gaming just before you acquire 1.
At this time, and in a good location, the leader should
set up a few anchors and belay the second climber so he can climb up and
hand off the equipment he has been recovering. The history of diamond simulants starts with the history of real diamonds which have to be known and treasured before some enterprising person gets around to imitating them with a cheap
substitute. In general, it is something manufactured, to pretend to be (or simulate), something else more
valuable.

Анонимный комментирует...

One of her most popular products are her organic vegetable seedlings, especially the tomatoes, which are cool-weather varieties that do
well on California's foggy Central Coast. Due to the popularity of organic gardening, organic potting soil and compost are available at most garden centers. In some cases, the quantity of materials for making compost in the amounts desired (an annual layer 2 inches deep across the garden) cannot be obtained.

My blog post :: appall

Анонимный комментирует...

А вот он и СПАМ!