Я думаю, все, кто сейчас читают эту статью так или иначе знакомы с сервисами аналогичными ПингАдмину или ХостТрекеру. Основное их предназначение — мониторить ваши сайты/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, то:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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