Пользователь
0,0
рейтинг
27 октября 2009 в 13:21

Администрирование → monit — наблюдатель за системными процессами

Теория

Monit — самостоятельный демон, работающий от пользователя root. Демон работает на Linux, Free/Net/OpenBSD, SUN Solaris и некоторых других UNIX-системах. Это OpenSource проект, у которого есть «старший брат» — коммерческий проект MMonit. Последний обладает более широким функционалом в вопросе массового мониторинга, межсетевого взаимодействия и составления отчетов. Идея авторов проста — для одиночного сервера используем Monit, для большой сетевой фермы — MMonit.



В зависимости от настроек, демон может проверять:
  • Существование процесса по PID
  • Работу определенного порта (TCP/UDP)
  • Ответ определенного протокола по определенному порту (SMTP, SSH, HTTP...)
  • Ресурсы, занимаемые процессом (CPU time/RAM)
  • MD5 checksum
  • Объем и свободное пространство в файловой системе
  • Количество активных (и суммарное) i-node-в
  • Права доступа к файлу или каталогу

Никто не запрещает комбинировать различные методы проверки. Для одного объекта проверки (тесты) зависят друг от друга, то есть сначала проводится тест1, если он прошел без ошибок — тест2, затем — тест3 и т.д.

В случае, если какой-то тест не пройден, monit может:
  • Остановить, стартовать или перезапустить демона
  • Подождать определенное время
  • Уведомить админа (почтовым сообщением)
  • Примонтировать, отмонтировать или перемонтировать файловую систему
  • Запустить отдельный скрипт (заранее написаный админом), причем передать ему определенные параметры (имя процеса/текст ошибки и т.д.)

Действия также никто не запрещает комбинировать, например:
Если HTTPd занимает более 200 мегабайт — ждать минуту, если ничего не изменилось — перезапустить сервис, если это также не помогло — прождать пять минут. Если и это не помогло — остановить сервис и уведомить админа письмом.

И еще. У Monit есть собственный http-сервер. Злоупотреблять им не стоит, так как работает он с рутовыми привилегиями, но иметь доступ к веб-консоли может быть крайне полезным. Вебсервер будет рассмотрен отдельно, в этой же статье.

Установка и настройка

Монит есть практически во всех широко распространенных дистрибутивах. В Debian, CentOS и Suse он так и называется. Во FreeBSD лежит в PORTS/sysmgmt/monit. Ставится он стандартным для операционной системы способом, и я не буду на этом подробно останавливаться.
Результатом установки будет собственно демон (monit) и файл конфигурации, который живет тут:
# Linux, Solaris:
 /etc/monit/monitrc
# FreeBSD/OpenBSD/NetBSD
 /usr/local/etc/monitrc

Конфиг очень подробно документирован, его рекомендуется почитать. Там есть подробные примеры и вообще много чего интересного. В принципе большую часть дефолтных настроек можно не трогать, ограничившись только необходимыми изменениями:

# процесс работает как демон, цикл проверки - 120 секунд.
# длительность цикла можно менять, это основная единица времени для monit. 
# Раз в цикл срабатывают проверки и выполняются команды от админа, присланные через веб-интерфейс
set daemon 120
# сервера, через которые пойдет почтовое уведомление. Можно делать несколько, очередность срабатывания повторяет очередность внесения
set mailserver mail.zooclub.ru 10025,
    localhost
# кто получит уведомление?
set alert sysadmin@zooclub.ru


Информацию о том, что monit должен проверять, можно хранить и в отдельном файле (файлах), которые подключаются в основной конфиг командой include:

# один файл
include /etc/devel/monitcheck.monitconf
# все файлы с расширением из папки.
include /etc/stable/monit/*


Мне кажется, что удобнее хранить проверку каждого сервиса в отдельном файле — это облегчает отладку и упрощает администрирование.

Мониторим состояние сервера в целом:
  check system ws1.zooclub.ru
    if loadavg (1min) > 4 then alert
    if loadavg (5min) > 2 then alert
    if memory usage > 75% then alert
    if cpu usage (user) > 90% then alert
    if cpu usage (system) > 40% then alert
    if cpu usage (wait) > 20% then alert

Файловые системы:
# /etc/stable/monit/filesystem.conf

# проверяем устройство по точке монтирования. 
#  Можно проверять диски напрямую (/dev/hda), но с LVM и прочими логическими "дисками" этот фокус не прокатит, 
#  их проверять можно только по точке монтирования и никак иначе.
check device homefs with path /home
        start program  = "/bin/mount /home"
        stop program  = "/bin/umount /home"
        if failed permission 755 then alert
        if failed uid root then alert
#  Если места остается меньше 20% минимум пять проверок за последние 15 - бить в набат и больше ничего не делать.
# При любой своей активности monit будет предупреждать админа письмом.
        if space usage > 80% for 5 times within 15 cycles then alert
#  Место кончилось, отмонтировать файлсистему
        if space usage > 99% then stop
# аналогично про i-nodes.
        if inode usage > 80% then alert
        if inode usage > 99% then stop
        group server

check device rootfs with path /
        start program  = "/bin/mount /"
# Потерять / во время работы сервера - безрадостная перспектива. По этому если дело плохо - просто перемонтируем его в read-only
        stop program  = "/bin/mount -o remount,ro /"
        if failed permission 755 then unmonitor
        if failed uid root then unmonitor
        if space usage > 80% for 5 times within 15 cycles then alert
        if space usage > 99% then stop
        if inode usage > 80% then alert
        if inode usage > 99% then stop
        group server

check device bootfs with path /boot
         start program  = "/bin/mount /boot"
        stop program  = "/bin/mount -o remount,ro /boot"
#  эта конструкция "отключит" тестирование файлсистемы, если права на папку - не 755
        if failed permission 755 then unmonitor
        if failed uid root then unmonitor
        if space usage > 80% for 5 times within 15 cycles then alert
        if space usage > 99% then stop
        if inode usage > 80% then alert
        if inode usage > 99% then stop
        group server

Теперь проверим работу веб-сервера apache:
# /etc/stable/monit/apache.conf
# проверка файла (размер, права доступа и тп):
check file apache_bin with path /usr/local/apache/bin/httpd
        if failed checksum and
# sum - это стандартный md5-хэш. Его можно получить, натравив программу md5sum на нужный файл
                expect the sum 8f7f419955cefa0b33a2ba316cba3659 then unmonitor
        if failed permission 755 then unmonitor
        if failed uid root then unmonitor
        if failed gid root then unmonitor
# отдельное письмо на отдельный адрес и с отдельным содержимым. 
        alert security@zooclub.ru on {
                checksum, permission, uid, gid, unmonitor
                } with the mail-format { subject: Alarm! }
        group server

# проверка процесса осуществляется по pid-файлу. Путь к pid-файлу всегда абсолютный
check process apache with pidfile /var/run/apache2.pid
        start program = "/etc/init.d/apache2 start"
        stop program  = "/etc/init.d/apache2 stop"
        if cpu > 60% for 2 cycles then alert
# если вебсервер сожрал 80% процессрного времени и не отдает его пять циклов проверки подряд - рестартуем его
         if cpu > 80% for 5 cycles then restart
# аналогично по суммарной памяти, которую он поглотил.
        if totalmem > 500.0 MB for 5 cycles then restart
        if children > 250 then restart
# если load average сервера за 5 минут больше 10 8 циклов подряд - вырубаем.
        if loadavg(5min) greater than 10 for 8 cycles then stop
# вот тут самое интересное - многоэтапная проверка:
# первый шаг - подключение на 80 порт, протокол http
        if failed host 127.0.0.1 port 80 protocol http
# если получилось - запрашиваем файл /index.html
                and request "/index.html"
                with timeout 15 seconds
# а если что-то из цепочки не получилось - рестартуем демон
                then restart
# проверка HTTP-SSL. Монит отдельно рассматривает SSL, и отдельно - защищаемый протокол.
# Для того, чтобы иметь возможность проводить такие проверки, нужно собрать monit с поддержкой SSL. 
# Любители FreeBSD - будьте внимательны при сборке!
# По умолчанию он долежен собратся с поддержкой SSL, но если вы ее отключили - будет ошибка
        if failed port 443 type tcpssl protocol http
                and request "/test.html"
                with timeout 15 seconds
                then restart
# если за последние пять циклов проверки было три рестарта или больше - пропускаем один цикл проверки.
        if 3 restarts within 5 cycles then timeout
# проверку имеет смысл проводить только, если пройдена первая проверка (которая права доступа и проч). 
# В противном случае все тесты безсмысленны.
        depends on apache_bin
        group server


OpenSSHD:
check process sshd with pidfile /var/run/sshd.pid
        start program "/etc/init.d/ssh start"
        stop program "/etc/init.d/ssh stop"
        if failed port 22 protocol ssh then restart
        if 5 restarts within 5 cycles then timeout
        group server


OpenVPN. Проверяем только наличие процесса:
check process openvpn with pidfile /var/run/openvpn.link1.pid
   group system
   start program = "/etc/init.d/openvpn start"
   stop  program = "/etc/init.d/openvpn stop"
   if 5 restarts within 5 cycles then timeout

PostgreSQL. Проверяем доступность через TCP-порт и сокет

check process postgres with pidfile /var/run/postgresql/main.pid
        group database
        start program = "/etc/init.d/postgresql start"
        stop  program = "/etc/init.d/postgresql stop"
        if failed unixsocket /var/run/postgresql/.s.PGSQL.5432 protocol pgsql then restart
        if failed host 127.0.0.1 port 5432 protocol pgsql then restart
        if 5 restarts within 5 cycles then timeout
	group database


Исчерпывающий список протоколов и вариантов проверки можно почерпнуть в документации. Правда, она на англ языке.

Веб-морда

Как я уже писал во вступлении, у monit есть небольшая, но довольно полезная вебморда.
Пример настройки:

# включить веб-интерфейс на определенный порт
set httpd port 10001 and
# включить SSL
        ssl enable
# где взять pem-файл. Нужен для ssl, подробно ниже
        pemfile /etc/monit/monit.pem
# на каком адресе (интерфейсе) слушать.
# если адрес не указать - слушать будет на всех
        use address 10.10.10.21
# разрешить доступ только с определенных адресов
# строго рекомендуется!
        allow 10.10.10.22/32
        allow 10.10.12.0/24
# разрешить доступ только знающим пароль.
# пароль, к сожалению, хранится в открытом виде
        allow senegami:aoLouch0aingahce
        allow logan:Jefae2Othaitae1S


Теперь о pem-файле. Веб-сервер monit довольно примитивный, и ему нужно иметь ssl сертификат, ключ от него и DH-файл в одном объекте. Собственно, он и называется pem-файлом. Готовится следующим образом. Сначала создадим шаблон для сертификата:

 ----- BEGIN:monit.cnf -----
#  create RSA certs - Server

RANDFILE = ./openssl.rnd

[ req ]
default_bits = 1024
encrypt_key = yes
distinguished_name = req_dn
x509_extensions = cert_type

[ req_dn ]
countryName = Country Name (2 letter code)
countryName_default = RU

stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = NorthWest

localityName= Locality Name (eg, city)
localityName_default= Saint Petersburg

organizationName= Organization Name (eg, company)
organizationName_default= AnyOne LLC

organizationalUnitName= Organizational Unit Name (eg, section)
organizationalUnitName_default= Net

commonName= Common Name (FQDN of your server)
commonName_default= ws1.zooclub.ru

emailAddress= Email Address
emailAddress_default= security@zooclub.ru

[ cert_type ]
nsCertType = server
----- END:monit.cnf -----

Разумеется, нужно поменять значения под необходимые конкретно вам

Затем соберем из шаблона сертификат:
openssl req -new -x509 -days 720 -nodes \
-config ./monit.cnf -out /etc/monit/monit.pem \
-keyout /var/certs/monit.pem

# Генерируем число Диффи-Хеллмана и прячем его в тот же файл
openssl gendh 512 >> /etc/monit/monit.pem

# проверяем читаемость сертификата
openssl x509 -subject -dates -fingerprint -noout -in /etc/monit/monit.pem

# Поскольку в файле лежит серкретный ключ сертификата - уменьшим права доступа
chmod 400 /etc/monit/monit.pem

После чего перезапускаем монит и любуемся :)
@logan
карма
0,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

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

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

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

  • 0
    Спасибо за развернутые примеры обязательно на досуге по экспериментирую, может где в продакшене пригодится.
  • 0
    извините за ламмерский вопрос, на сколько реально мониторинг нескольких серверов по WAN? ну т.е. образно из других датацентров с одной основной ноды?
    • 0
      Вполне реален, но не советую средствами Monit. Используйте Zabbix или Munin (о нем я тоже напишу, возможно даже сегодня)
    • 0
      Вполне реально. Но не монитом — он ориентирован не на мониторинг, а на поднятие упавших сервисов. Апач перезапустить, например, или zabbix (который очень любит падать).
  • 0
    Забавное решение.
    Но, учитывая, что бесплатная версия поддерживает только один хост для мониторинга и имеет уж совсем скудный веб-интерфейс, проще сразу обратить внимание на тот же Zabbix.
    • +1
      Монит — это решение для одного сервера, ставить туда заббикс — очень ресурсозатратно. :)
      • –1
        Решение какое-то уж узкоспециализированное получается.
        • +1
          Не скажите. Простейшее слежение за сервисами на одном сервере с перезагрузкой упавших — вполне себе работоспособно.
  • 0
    Во FreeBSD лежит в PORTS/sys-utils/monit.


    На самом деле — в $PORTSDIR/sysutils/monit/

    # FreeBSD/OpenBSD/NetBSD
     /usr/local/etc/monit/monitrc
    


    Во FreeBSD конфиг лежит по умолчанию в /usr/local/etc/monitrc

    # Для того, чтобы иметь возможность проводить такие проверки, нужно собрать monit с поддержкой SSL.
    # Любители FreeBSD — будьте внимательны при сборке!


    Во FreeBSD monit собирается с поддержкой SSL по умолчанию.
    • 0
      Счас поправим, спасибо.
      • 0
        Еще man openssl говорит что gendh obsoleted by openssl dhparam, поэтому лучше вместо openssl gendh 512 написать openssl dhparam -2 -outform PEM
  • –1
    Вот это высший пилотаж в администрировании!
  • 0
    используем вна серваках для слежения и поднятия упавших процессов.
    из минусов — не умеет без пида отслеживать процесс.
    выкрутились: т.к сервис веб-ориентирован, то проверяется урл на отдачу заданного текста
    и если не получось — рестарт )
    check host host with address xxx.yyy.com
       start program = "/etc/init.d/spawn-service start"
       stop program = "/etc/init.d/spawn-service stop"
    
        if failed url
           http://xxx.yyy.com/
           and content == 'i am alive'
           with timeout 30 seconds
           then restart
    
      if failed url http://xxx.yyy.com/
            CONTENT !=  "The page you are looking for is temporarily unavailable"
            timeout 60 seconds 3 cycles
       then restart
    


    • 0
      Я добавлю в статью, вы не против?
      • +1
        мы, николай второй, не против )
        • 0
          только добавьте плз коммент
          для первого случая
          if failed url
                 http://xxx.yyy.com/
                 and content == 'i am alive'
          

          — рестарт в случае ненахождения данной строки

          для второго
            if failed url http://xxx.yyy.com/
                  CONTENT !=  "The page you are looking for is temporarily unavailable"
                  timeout 60 seconds 3 cycles
             then restart
          

          рестарт если строка найдена за 3 цикла проверки.
          ( сообщение — стандартное nginx если упал бек-энд. )

  • 0
    Хочу добавить, что именно monit держит на плаву АТС Alcatel со встроенным линуксом =) Так что можно считать, что «Alcatel рекомендует в продакшен». А вообще, это решение является отличным дополнением к системам мониторинга типа Nagios или Zabbix — иногда может сетевой интерфейс на самом мониторящемся серваке упасть, и фиг Zabbix что с ним удалённо сделает. А monit локально может попытаться решить проблему.
  • 0
    Есть несколько неудобных мелочей (может в свежих версиях поправили?):
    1. Почта отправляется только через smtp (локальный /usr/sbin/sendmail низзя, да)
    2. Нет возможности написать свой обработчик почты (ну, вытекает из первого). Например, что б уведомления слались не на почту, а вызывался свой скрипт, отправляющий sms/jabber-сообщение. Мне в почту валится и так очень много (часто важного) мусора от десятка серверов, сообщения от monit могу случайно пропустить, да и jabber/sms всё-таки быстрее доходят, чем email.
    • 0
      Ставьте mmonit, он умеет jabber. :)
      • 0
        Комерческий :(
        • 0
          Угу, проприетарный. Но бесплатная версия есть, в разделе загрузок.
          • 0
            Мне не настолько критичен mmonit, что б использовать его (бинарник, нет в репозитории и прочие прелести). Для чего-то очень важного есть гейты mail->sms, просто это всё создаёт мелкие неудобства.
    • 0
      Когда-то у меня была похожая проблема с другим софтом. Суть была в следующем: софт мог только по SMTP отправить что-либо. Необходимо было выдернуть это и заслать другими путями. Что было сделано:
      1. Установлен QMail.
      2. Установлено расширение qmail-spp (http://qmail-spp.sourceforge.net/).

      Суть расширения в том, что оно подхватывает SMTP сессию QMail и реагирует на указанные Вами комманды, вызывая указанный скрипт / программу.
  • +1
    Про монит на хабре уже писали :) Кроме того у него конфиги интуитивно понятны. Но за старания спасибо.
  • 0
    обязательно опробую что за зверь
    спасибо автору
    • 0
      а то я недавно сам изобретал велосипед
      о котором хотел поделиться в блоге
    • 0
      но в том велосипеде кроме мониторинга еще есть элементы управления:
      отслеживание зависания, контроль по объему памяти

  • 0
    Отличная вещь.
    Требовался именно этот функционал и простота настройки.
  • 0
    Использую Монит, но просьба к сообществу помогите с таким вопросом (в документации нет примера).
    Как указать Монит выполнить скрипт, когда связь с Интернет была восстановлена. То есть был период в который Интернет через ADSL был не доступен, потом связь восстановилась и нужно выполнить скрипт при работающем Интернете.
  • 0
    Пытался найти в документации, но не могу — как сделать алерт, если некий процесс висит уже слишком давно, но он занимает жалкий 1% или даже меньше, и вычислить его про average нагрузке нельзя.

    То есть просто, если процесс накопил xx минут по CPU, хотелось бы отправить алерт или прибить.
    Как я понял, в monit такого триггера нет?
  • 0
    Отпишусь по поводу граблей, на которые я очень больно наступил: если в конфиге поставлена задержка при запуске monit, то он не начнет слушать свой интерфейс пока она не истечет. На время отладки конфигурации стоит эту задержку отключить.

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