Debian.pro/

Про Debian


Создаём свой собственный маленький host-tracker/ping-admin: Monit для мониторинга внешних сущностей.

Я думаю, все, кто сейчас читают эту статью так или иначе знакомы с сервисами аналогичными ПингАдмину или ХостТрекеру. Основное их предназначение — мониторить ваши сайты/http-ручки и ругаться в почту (дешево) или в смс/звонком (дорого) вам, если что-то сломалось/починилось.
На днях один из таких сервисов меня подвел (не отправил уведомления, когда умер mysql на ОченьВажномСервере) и в итоге о поломке я узнал через почти 12 часов по другим характерным признакам (а если быть точным — то очень недовольным, мягко говоря, звонкам от владельца сервера…). В общем-то, такая ситуация мне совершенно не нравится, поэтому я провел выходные в попытках сделать нечто своё, что не будет зависеть от кого-либо. Получилось без блэкджека (смс-ок) и шлюх (приятного женского голоса робота, который звонит мне и зачитывает, что там у меня сломалось), но мне и так подходит — почту я читаю внимательно и часто.

В итоге я пришел к таким выводам:
1) заводим почтовый ящик где-нибудь снаружи
2) покупаем 2 виртуалки в разных странах (у меня одна в Голландии, вторая в Германии).
3) на обоих настраиваем почтовый сервер, который будет выступать бэкапом на тот случай, если Яндекс (в моём случае) перестанет слать мою почту.
4) на обеих виртуалках настраиваем Monit.
5) настраиваем оба monit-а, чтобы они мониторили друг-друга и самих себя.
Вообще monit написан для того, чтобы следить за состоянием локального сервера (смотреть, чтобы не упали процессы, что какой-то импорт выполнился за последние 24 часа). Но есть у него приятные особенности, которые нам помогут — он умеет слать алерты по почте, если состояние какого-то сервиса изменилось. И умеет мониторить внешние http-ручки/порты/пинговать серверы. Конечно, «правильная» архитектура, по мнению разработчиков, состоит в установке инстанса monit на каждый наш сервер и покупки M/Monit (от 65 евро за 5 хостов до 429 за безлимитную), но мы то люди бедные, кхе. Да и сам M/monit ставить куда-то нужно (а один инстанс M/Monit — одна лицензия). А вдруг упадёт… В общем, прикинув, что платить мне нужно будет, как минимум, 580 евро, я пошел читать доки. Нужно сказать, что нижеописанное найти в доках сходу (а тем более не зная, что искать) — немного проблематично =)
Пытливые умы сейчас таращатся в эту статью про себя проговаривая мантру «Zabbix, Nagios, Ichinga,Zabbix, Nagios, Ichinga». Я ничуть не против — настраивайте. На них я тоже смотрел, но как-то оно всё не попадает в категорию «мне бы тут что-нибудь простенькое, чтобы письма писало». А эффект — тот же, что и от monit, в итоге. Разве что, к ним смс-ки прикрутить можно через модем или внешнее api (но к monit нехитрым образом тоже можно — достаточно слать письма на отдельный ящик яндекспочты (которая умеет смски о новых письмах слать), или вообще использовать любой внешний mailtosms транспорт).

Ну, собственно, поехали. Пунктом первым у меня было создание внешнего ящика. На помощь пришел pdd, подключенный к одному из доменов. Самое главное — пойти в интерфейс своего ящика и намекнуть ему, что письма от адреса, который вы используете для мониторинга, никогда нельзя класть в спам. Учтите, что если вы собираетесь использовать цепочку вида «слать письма мониторинга на один ящик, оттуда форвардить на другой» — то скорее всего, эти письма вы потеряете (например, у меня был настроен форвардинг с Яндекса в gmail, но Яндекс не пересылает спам на другие ящики (даже если пошаманить с фильтрами на стороне ящика, с которого вы собираетесь форвардить почту)). Собственно, если у вас свой домен — то проблем быть не должны, настройте почтовик корректно, настройте SPF/A/PTR записи, hostname машинки — и письма никуда теряться не будут. Но если у вас обычный ящик (@yandex.ru, например), то в качестве бэкапного решения мы будем отсылать письма от имени этого ящика прямо со своего сервера — а такое письмо точно улетит в спам. Переложить во входящие вы его сможете при помощи фильтра «Никогда не класть письма в спам от получателя …», но сфорвардить такое письмо на другой ящик будет уже нельзя. В общем, с почтой в этом месте нужно быть очень аккуратным.

Берем виртуалку (отдельную, само собой — мониторить сервер с самого сервера немного неразумно) или две (соответственно, тогда всё настраиваем на обеих) с debian (или бубунтой, в принципе, подойдет) и начинаем настраивать monit.
Ставим monit. Если у нас debian wheezy, то:

root@server:~# echo "deb http://cdn.debian.net/debian wheezy-backports main contrib non-free" >> /etc/apt/sources.list
root@server:~# apt-get -qq update; apt-get install -t wheezy-backports monit

Если что-то другое и вы не знаете, откуда там легально добываются новые версии пакетов, то просто:

root@server:~# apt-get -qq update; apt-get install monit

Откладываем в сторону дефолтный конфиг:

root@server:~# mv /etc/monit/monitrc /etc/monit/monitrc.bak; touch /etc/monit/monitrc; chmod 0600 /etc/monit/monitrc

Пишем в /etc/monit/monitrc вот такое:

# периодичность всех проверок раз в минуту:
set daemon 60

# пути до лога и служебных файлов:
set logfile /var/log/monit.log
set idfile /var/lib/monit/id
set statefile /var/lib/monit/state


# настройки почты, на примере яндексовой
# само собой, вместо somesmtpuser@yandex.ru пишем свой почтовый логин, вместо somepassword - пароль от ящика
# вместо smtp.yandex.ru адрес smtp-сервера.
# запятая в конце обязательна, если будете указывать бэкапные серверы
set mailserver smtp.yandex.ru port 25 username "somesmtpuser@yandex.ru" password "somepassword",
  # описываем "последний резерв" - будет использован локальный почтовый сервер (запятой в конце нет):
  localhost

# описываем очередь внутри monit.
# советую задрать циферку slots, если у вас будет много проверок
set eventqueue
  basedir /var/lib/monit/events
  slots 100

# от какого пользователя слать почту (это не smtp-аккаунт, а то, что будет указано в заголовке From).
set mail-format { from: somesmtpuser@yandex.ru }

# указываем самый главный админский ящик, на который будут отправляться все уведомления от monit:
set alert yourownmail@domain.tld

# включаем dashboard для monit - встроенный веб-сервер, на котором будет крутиться страничка, на которой можно будет посмотреть актуальное состояние нашего хозяйства.
# в данном случае, нам нужно будет зайти на http://yourserver:2812/ с логином admin и паролем pass
set httpd port 2812 and
  use address 0.0.0.0
  allow 0.0.0.0/0.0.0.0
  allow admin:pass

# подключим каталог, в котором будем хранить конфиги проверок:
include /etc/monit/conf.d/*

Теперь можно начинать писать конфиги проверок.
Я стараюсь описывать каждую проверку отдельно — во-первых, так удобнее дашборд просматривать, во-вторых, на каждую проверку в таком случае будет отсылаться отдельное письмо. Ну и для отдельно описанных проверок можно выдавать разные «имена хостов» внутри monit — тогда по заголовку письма сразу видно, что там сломалось. Заодно можно будет выставить на каждую такую проверку разные получателей писем (например, своему помощнику слать письма о raid-ах, а девопсу письма о том, что у него какая-то api-шная ручка сломалась).

В мануалах по monit можно встретить такой формат описания проверок:

check host hostname with address some.ip.address
    if something then alert
    if something2 then alert

(где something — сама проверка)

Вот таким форматом я как раз и стараюсь не пользоваться. Помимо описанного абзацем выше, есть очень большая проблема — monit высылает только одно письмо, даже если сломались все проверки на хосте. То есть — вы спите ночью, вам приходит письмо о том, что raid сломался. Чешете репу, потягиваетесь, произносите «да ну его, утром починю!». А утром оказывается, что на самом деле упал весь сервер — просто raid-проверка первая по счету (и письмо было отправлено именно по ней).

Дабы такого не случилось, пишите проверки в том формате, который я описываю ниже ;)

Поехали мониторить свой первый сервер. Создаём файл /etc/monit/conf.d/server1.conf
Внутрь мы напишем вот такую ересь:

# проверяем сервер по адресу server1.domain.tld (вместо этого может быть и dns-имя сервера, и ip-адрес)
# проверка будет иметь название server1-raid
check host server1-raid with address server1.domain.tld
    # Описываем саму проверку:
    # если нам не удалось получить ответ по урлу http://server1.domain.tld:1500/raids с текстом 0;OK 2 цикла подряд (цикл у нас 60 секунд, если вы его не меняли - задаётся опцией set daemon 60 в monitrc),
    # то отправляем письмо
    if failed url http://server1.domain.tld:1500/raids and content == "0;OK"
    with timeout 10 seconds
    for 2 cycles

    then alert

# описываем вторую проверку.
# в данном случае - icmp-проверка.
# все почти то же самое, пинговать мы будем server1.domain.tld
# "название" хоста будет server1-ping
check host server1-ping with address server1.domain.tld
    # если сервер перестал пинговаться, то помимо вас, ребутнуть его сможет младшая уборщица.
    # добавим её в список получателей алерта (на ящик указанный в monitrc письмо тоже будет отправлено, независимо ни от чего):
    alert junior-janitor@yourcompany.tld
    # если сервер не ответил на 3 пинга подряд с таймаутом/периодом цикла в 10 секунд - ругаемся и пишем письма уборщику:
    if failed icmp type echo count 3 with timeout 10 seconds
    then alert

# описываем третью проверку - будем тыкаться в наш многострадальный сервер на 3306 порт и проверять, что там всё ещё mysql крутится, а не левое поделие
check host server1-mysql with address server1.domain.tld
    # mysql сервер в вашей компании могут перезапустить аж целых 2 dba, кроме вас.
    # Пусть тоже получают письма счастья, а то чего они спят.
    alert dba1@yourcompany.tld
    alert dba2@yourcompany.tld
    if failed port 3306 protocol mysql with timeout 10 seconds then alert

Ладно, сервер мы замониторили. Для закрепления знания мы замониторим пару сайтов. Да ещё и так, чтобы их владельцы тоже получали письма. Само собой, сайты не бог весть какая важная штука, поэтому им можно полежать 2-3 минуты, прежде чем мы узнаем об этом.

Пишем в файл /etc/monit/conf.d/sites.conf

check host site1.tld with address site1.tld
    alert director@site1.tld
    if failed url http://site1.tld with timeout 5 seconds for 3 cycles then alert

check host site2.tld with address site2.tld
    alert director@site2.tld
    # а этот сайт у нас по https, но monit умный, он и такое умеет!
    if failed url https://site2.tld with timeout 5 seconds for 3 cycles then alert

Вот. Вроде всё. Рестартим monit:

root@server:~# /etc/init.d/monit restart

Проверяем, что мы получили письмо с заголовком «monit alert — Monit instance changed», радуемся.
Если письма не получили — то смотрите в

root@server:~# cat /var/log/monit.log | grep error

почему письмо не отправилось.

Да, если вы не знаете, как мониторить всякие raid/свободное место на сервере снаружи по http, а скрипты умеете писать только на bash — то почитайте эту статью.

Поменьше вам поломок ;)


Комментарии (2):

  1. Григорий :

    А для пересылки почты удобно использовать GMail, да только не gmail.Com а gmail.Ru благо последний как раз пересылкой почты и занимается :)

  2. Для пересылки удобно использовать вообще любой сервис почтового форвардинга. Вот только рано или поздно за пересылку «спама» их банят на принимающей стороне (на том же gmail.com). При том банят с концами — не разрешают вообще присылать письма.

Написать комментарий