Monit hlídá, že služby běží, a zvedá je, když spadnou. První otázka, která se tu nabízí: proč to, když systemd umí totéž jedním řádkem Restart=always?

Odpověď určuje celé nastavení. systemd vidí, že proces skončil, a spustí ho znovu. Neví, zda služba odpovídá na požadavky. PHP-FPM, který narazil na limit procesů, je pro systemd živý a zdravý, a web přitom vrací 502. MySQL, kterému došlo místo, dál běží jako proces a neprovede jediný dotaz. Monit nekontroluje existenci procesu, ale jeho chování: odpovídá port, co vrací HTTP požadavek, kolik je obsazeno paměti.

Odtud pravidlo: systemd necháváme, jak je, a Monit přidáváme kvůli funkčním kontrolám. Zdvojovat restart spadlého procesu nemá smysl.

Nastavení

sudo apt install monit

Hlavní soubor je /etc/monit/monitrc, vlastní kontroly se ukládají jako samostatné soubory do /etc/monit/conf.d/. Začátek je obvyklý:

set daemon 60
set logfile /var/log/monit.log
set mailserver localhost
set alert admin@example.com

Dotaz jednou za minutu je rozumná rovnováha. Častější přidává zátěž a zvyšuje riziko chybného restartu kvůli vteřinovému zdržení.

Webové rozhraní: jen lokálně

Monit má vestavěnou webovou stránku a ve výchozím stavu se zapíná přibližně tak, jak ukazuje první nalezený návod — na všech adresách. Vznikne ovládací panel služeb serveru dostupný z internetu. Správná varianta:

set httpd port 2812 and
    use address localhost
    allow localhost
    allow admin:'dlouhe-heslo'

Přístup zvenčí přes SSH tunel:

ssh -L 2812:localhost:2812 user@203.0.113.25

Poté se stránka otevírá na vlastním počítači na adrese localhost:2812 a ven nic netrčí.

Kontroly, které dávají smysl

Webový server — ne podle existence procesu, ale podle odpovědi:

check process nginx with pidfile /run/nginx.pid
    start program = "/bin/systemctl start nginx"
    stop program  = "/bin/systemctl stop nginx"
    if failed host 127.0.0.1 port 80 protocol http
        request "/" status = 200
        for 3 cycles then restart
    if 3 restarts within 10 cycles then unmonitor

Tři řádky jsou zde důležitější než ostatní.

protocol http ... status = 200 — to je právě ta kontrola, kvůli které se do toho šlo: server musí vrátit stránku, ne jen držet otevřený port.

for 3 cycles — nereagovat na ojedinělý výpadek. Bez toho Monit restartuje službu kvůli jediné pomalé odpovědi pod zátěží, čímž situaci jen zhorší.

if 3 restarts within 10 cycles then unmonitor — povinný řádek. Pokud se služba nezvedá kvůli chybě v konfiguraci, bude ji Monit restartovat donekonečna, přidávat zátěž a zaplňovat logy. Tento řádek znamená: tři neúspěšné pokusy — přestat a zanechat zprávu. Dál je potřeba člověk, automatika už nepomůže.

Místo na disku se kontroluje zcela bez automatiky, prostě zprávou:

check filesystem rootfs with path /
    if space usage > 85% then alert
    if inode usage > 85% then alert

Řádek o i-uzlech je potřeba zvlášť: docházejí nezávisle na místě a bez něj tato situace zůstane nepovšimnuta.

Kontrola konfigurace

sudo monit -t
sudo systemctl reload monit
sudo monit summary
sudo monit status

monit -t ověří syntaxi před nasazením. monit summary dá krátkou tabulku stavů — od ní stojí za to začínat rozbor jakéhokoli problému.

A ověřte odesílání pošty. Monit hlásí události dopisem, a pokud odesílání není nastaveno, upozornění nepřijde — služba se restartuje, vy se to nedozvíte, a právě opakované restarty jsou hlavní signál. Vidět je lze i v logu: /var/log/monit.log.

Co Monit nedělá

Neodstraňuje příčinu. Restart je odklad a neustále restartovaná služba znamená, že někde nestačí paměť, dochází místo nebo teče aplikace. Hodnota nástroje není v samotném restartu, ale v čítači: tři restarty nginxu za den jsou diagnóza, která by jinak zůstala nepovšimnuta, protože web celou tu dobu fungoval.

Proto je třeba dívat se ne na aktuální stav (ten je téměř vždy zelený), ale na historii: kolikrát se za týden něco zvedlo samo. Jak to vypadá na jedné stránce, ukazuje ukázka níže.