MonIT + M\MonIT = простой и бесплатный мониторинг нескольких серверов

Возникла задача мониторинга нескольких серверов, находящихся в разных ДЦ, имеющих разные ОС и ПО.

ТЗ получилось примерно такое:

  1. Мониторинг системы (cpu, mem, load average, bandwidth).
  2. Мониторинг состояния сервисов (запущен или нет).
  3. Мониторинг функционирования сервисом (отвечает на запросы корректно или нет).
  4. Контроль потребляемых сервисами ресурсов и общего их состояния.
  5. Централизованая «админка» для всей этой радости.
  6. Уведомление по email, самостоятельное исправление проблемы (например рестарт упавшей службы).




Поиск решения.


В процессе изучения возможных вариантов были найдены 5 вариантов:

  • Nagios
  • Whats UP
  • Zabbix
  • Monit
  • Написание собственных скриптов


Первый и третий варианты были отброшены как слишком сложные в настройке и имеющие заведомо не нужный (хотя и огромный) функционал. Второй отброшен из-за феерической (995$) цены и требования сервера с MS Windows. В итоге я решил остановиться на Monit.

Что такое Monit?



Monit — бесплатное приложение с открытым исходным кодом, обеспечивающее комплексный мониторинг UNIX-like систем, как то:

  • Состояние серверов (доступность, потребление ресурсов).
  • Мониторинг демонов (состояние, потребляемые ресурсы, количество child-process и многое другое).
  • Мониторинг сетевых сервисов (возможность подключения и корректность ответа).
  • Выполнение встроенных (запуск\остановка\перезапуск) или собственных (скрипты) действий при достижении определенных событий.
  • Уведомление на email или в централизованный web-интерфейс M\Monit.


Основным приемуществами программы являются низкое потребление ресурсов, простота конфигурации (настройка 15-20 минут) и открытый исходный код.

Поддерживаются ОС GNU\Linux (есть в большинстве пакетных систем), FreeBSD (есть в портах), OpenBSD, Solaris, MacOS X. Windows в качестве сервера НЕ поддерживается, но мониторить сетевые сервисы расположенные на удаленной windows-машине это не мешает.

Архитектуры — x86, x86_64, PowerPC (Mac only), Sparc (Sun only).

Установка и базовая настройка.



Пакет есть для большинства дистрибутивов (Gentoo, Debian, FreeBSD — в основном дереве, CentOS, Fedora, RedHat — в репозитории dag). Пакет так и называется — monit.

Основной конфигурационный файл — /etc/monit.conf (в Linux) или /usr/local/etc/monitrc (в FreeBSD). В FreeBSD этот файл нужно создать:

# mv /usr/local/etc/monitrc.sample /usr/local/etc/monitrc

После чего нам нужно раскомментировать в конфигурационном файле строку:

include /etc/monit.d/*

Теперь все файлы конфигурации из /etc/monit.d/ будут автоматически подхватыватся monit-ом.

Я разбил свою конфигурацию на два файла (для удобства) — main.conf (общие настройки) и master.conf (настройки мониторинга сервисов).

main.conf


Для тех, кому лень читать комментарии на английском привожу его пример и перевод части комментариев.

set daemon 120 # Частота проверки сервисов.
set logfile syslog facility log_daemon # syslogd facility.
set mailserver localhost, # IP\hostname почтового сервера, через который пойдут уведомления.
set eventqueue # Разрешить очередь уведомлений.
basedir /var/log/monit # путь к каталогу, где будут храниться уведомления.
slots 100 # Максимальное количество уведомлений в очереди.

set mail-format { from: main-servers-alert@example.com } # От какого имени рассылать уведомления.
set alert admin@example.com #Ящик для _всех_ уведомлений (много).
set alert support@example.com { timeout } # Ящик для критических уведомлений (падение сервера\демонов).

check system *CHANGEME.HOSTNAME.EXAMPLE.COM* # Хостнейм сервера.
if loadavg (1min) > 6 then alert
if loadavg (5min) > 3 then alert
if memory usage > 75% then alert
if cpu usage (user) > 70% then alert
if cpu usage (system) > 30% then alert
if cpu usage (wait) > 20% then alert


Как видно, конфиг крайне прост и понятен.

master.conf


master.conf — в моем случае отвечает за мониторинг конкретных демонов.

Опять же привожу его пример (слепо копипастить _не_нужно_). Показываю на примере почтовика exim, по этой логике пишется такой блок под каждый демон, который нужно мониторить:

check process exim with pidfile /var/run/exim.pid # Название и PID.
start program = "/etc/init.d/exim stop" # Команда запуска.
stop program = "/etc/init.d/exim start" # Команда остановки.
if cpu > 60% for 2 cycles then alert # Если в течение двух циклов потребление CPU > 60% - уведомить.
if cpu > 80% for 5 cycles then restart # А если за 5 циклов больше 80% - перезапустить.
if totalmem > 300.0 MB for 5 cycles then restart # Если потребление памяти > 300мб - рестарт.
if children > 50 then restart # Если больше 50 чайлдов - рестарт.
if failed port 25 protocol smtp then restart # Если не отвечает на 25 порту по SMTP - рестарт.
if 5 restarts within 5 cycles then timeout # Если пять раз рестартовали и не помогло - timeout.


M\Monit



M\Monit — средство централизованного мониторинга серверов под управлением monit.

Сама программа платная, но пользоваться ей можно и бесплатно — на сайте выложена Free-версия, хотя и с определенными ограничениями.

Установка и базовая настройка.


Качаем версию для своей ОС и архитектуры, распаковываем архив.

Устанавливаем:

# mv mmonit-2.0.3 /usr/local/mmonit
# cd /usr/local/mmonit
# cp /usr/local/mmonit/doc/startup/mmonit_init /etc/init.d/mmonit


Создаем базу данных MySQL (также поддерживаются PgSQL и SQLite), вносим содержимое:

# cat /usr/local/mmonit/db/mmonit-schema.mysql | mysql -u -p monit


Редактируем /usr/local/mmonit/conf/server.xml. Формат конфига - XML. Для нас там интересен только один блок:

<Realm url="mysql://user:password@hostname/database"
minConnections="5"
maxConnections="250"
reapConnections="300" />


Можно запускать:

# /etc/init.d/mmonit start


Если запустилось нормально - заходим на localhost:8080. Логин admin, пароль swordfish

Теперь осталось настроить клиенты.

Связывание monit с m\monit


Для связывания клиента и центра управления, нужно в main.conf каждого сервера вписать:

set mmonit monit:monit@:8080/collector
set httpd port 2812 and use address allow localhost
allow allow monit:monit


После чего перезапустить мониторинг.

Осталось только зайти в админку и зарегистрировать появившиеся там серверы. Мониторинг готов. Мы сможем контролировать нагрузку на все серверы, работающих демонов и системные события.
+21
25 мая 2009, 22:47
72

комментарии (35)

0
vermus #
спасибо, попробуем на досуге. На продакшене использовали?
+1
rgaliull #
munin может не рассматривали?
0
Scrill #
По-моему Munin используется немного для других задач.
–2
KrasivayaSvo #
В App Store есть m\monit для iPhone.
+1
dodarium #
Nagios — 'это велика вещь. Очень сильно помогает мониторить свичи. сразу видно что и на како доме у нас упало.
+1
Draug #
Zabbix не менее приятен своими методами проверки доступности хоста. Хотя может сперва напугать неопытного админа своим мануалом и глюками.
0
NickyX3 #
Ох уж эти глюки…
Буквально на прошлой неделе расвернул его из debian Lenny пакета на одной ферме вместе с frontend-php. Работает.
На этой неделе пытался на фторой ферме поставить. Любой POST запрос в море приводит к висяку и таймауту по mex execution time. Скачал исходники, вонзил вебморду от 1.6. Работает…
0
differentlocal #
Согласен. Но для этой задачи его функционал избыточен.
0
borisko #
За нагиосом очень тяжело слледить при большом количестве серверов.
0
dodarium #
Если большое количество серверов и свичей, то смотреть по карте наверно не удобно. Но в нагиосе всегда это дело можно посмотреть списком. И тем более у нас и не запредельно много оборудования и мне кажется, что другого и не надо на моей работе.
0
Boiler #
Поддерживаю. Очень гибкая и функциональная вещь. Юзаю много лет.
0
odessky #
Что сложного в zabbix?
0
Draug #
Сразу сложно разобраться в айтемах, триггерах, экшенах, медиа типах и глюках(привет неработающее оповещение jabber-приходится скрипты свои юзать)… Тем более когда тебе мониторить надо всего менее 10 едениц оборудования.
0
differentlocal #
В принципе — ничего, но зачем осваивать электронный микроскоп, если нужно забить гвоздь?
0
non7top #
через год серверов станет 20-50 и придется-таки осваивать микрскоп, а потом еще и переводить старые сервера на новую систему
0
Shafeev #
Да прибудет с вами Opmanager.
0
kagen #
ещё есть UTC — UpTime Checker
Правда больше подходит для хостинга, но то же неплох. И цена не такая безумная.
0
Draug #
В отношении мониторинга хостинга мне очень понравились web-сценарии в Забиксе. Раньше всё это проделывал через bash+curl+cron.
0
seventh #
The Dude (Windows only). Большинство из предложенного делает по SNMP.
0
Draug #
Забавно :) «Runs in Linux Wine environment, MacOS Darwine, and Windows»
0
seventh #
ну wine'ы никто не отменял)
0
kalbas #
да, удобная штука этот «чувак» :) Использую…
0
fixx #
плюс заббикса в том, что все делает, чем вебморды, не нужно конфиги править.
0
Draug #
Для кого-то "+", а для кого — без «поллитры» эта морда как китайская грамота.
0
fixx #
я сначала сам ее пугался:) но в итоге все очень удобно и приятно.
0
Draug #
Да, согласен. Удобно. А ещё форум неплохой, есть русский раздел и ведётся активная разработка новой версии забби, много чего обещают. :)
0
alekciy #
Наверное все же не mv, а cp ;) Все же лучше иметь в системе дефолный файл конфига.
0
insa #
Монит очень негибкий. Например ему нельзя сказать, что рестарт сервиса надо делать только после N таймаутов по M секунд. Или, что start скрипт может отрабатываться в течении 10 секунд и в это время не надо пытаться перезапускать процесс…

Мониторинг должен быть более программируемым. Таким как mon (perl), или god (ruby), или свой скрипт на bash в кроне ,-)
0
DimkaPhantom #
Был печальный опыт использования монита на одном из серверов. Вся проблема не совсем в гибкой настройке. Хочется большего при мониторинге сетевых интерфесов. Наблюдение за ppp0 организовать не удалось.
0
ainu #
Откройте стартап)). Забугорный уже есть.
0
vinzz #
Вы про www.versiera.com?
0
cas_alexi #
zenoss посмотрите
0
parta #
да, казалось бы сладко, но вот с исходников хрен поставишь. особенно после релиза 2.4.0.
0
sergzah #
Для своего сервера использую Monit, на работе для мониторинга проекта — Zabbix. Автор абсолютно прав в том, что Zabbix крут, но это полный звездолет. Монит прост, интуитивно понятен и для решения задачи мониторинга совершенно определенных базовых вещей на *nix-сервере со стандартным дистром подходит на все 100%. Если че-то не хватает — можно по событиям запускать свои внешние скрипты.
0
MrMan #
уж если писать инструкцию по установке, так надо нормально писать.

Что это за строки типа:
set mmonit monit:monit@:8080/collector

или:
allow allow monit:monit

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

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