Monit stráži, že služby bežia, a dvíha ich, keď spadnú. Prvá otázka, ktorá sa tu ponúka: prečo to, keď systemd vie to isté jedným riadkom Restart=always?

Odpoveď určuje celé nastavenie. systemd vidí, že proces skončil, a spustí ho znova. Nevie, či služba odpovedá na požiadavky. PHP-FPM, ktorý narazil na limit procesov, je pre systemd živý a zdravý, a web pritom vracia 502. MySQL, ktorému došlo miesto, ďalej beží ako proces a nevykoná jediný dotaz. Monit nekontroluje existenciu procesu, ale jeho správanie: odpovedá port, čo vracia HTTP požiadavka, koľko je obsadené pamäte.

Odtiaľ pravidlo: systemd necháme, ako je, a Monit pridávame kvôli funkčným kontrolám. Zdvojovať reštart spadnutého procesu nemá zmysel.

Nastavenie

sudo apt install monit

Hlavný súbor je /etc/monit/monitrc, vlastné kontroly sa ukladajú ako samostatné súbory do /etc/monit/conf.d/. Začiatok je obvyklý:

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

Dotaz raz za minútu je rozumná rovnováha. Častejší pridáva záťaž a zvyšuje riziko chybného reštartu kvôli sekundovému zdržaniu.

Webové rozhranie: len lokálne

Monit má vstavanú webovú stránku a v predvolenom stave sa zapína približne tak, ako ukazuje prvý nájdený návod — na všetkých adresách. Vznikne ovládací panel služieb servera dostupný z internetu. Správny variant:

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

Prístup zvonka cez SSH tunel:

ssh -L 2812:localhost:2812 user@203.0.113.25

Potom sa stránka otvára na vlastnom počítači na adrese localhost:2812 a von nič netrčí.

Kontroly, ktoré dávajú zmysel

Webový server — nie podľa existencie procesu, ale podľa odpovede:

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

Tri riadky sú tu dôležitejšie než ostatné.

protocol http ... status = 200 — to je práve tá kontrola, kvôli ktorej sa do toho išlo: server musí vrátiť stránku, nie len držať otvorený port.

for 3 cycles — nereagovať na ojedinelý výpadok. Bez toho Monit reštartuje službu kvôli jedinej pomalej odpovedi pod záťažou, čím situáciu len zhorší.

if 3 restarts within 10 cycles then unmonitor — povinný riadok. Ak sa služba nedvíha kvôli chybe v konfigurácii, bude ju Monit reštartovať donekonečna, pridávať záťaž a zapĺňať logy. Tento riadok znamená: tri neúspešné pokusy — prestať a zanechať správu. Ďalej je potrebný človek, automatika už nepomôže.

Miesto na disku sa kontroluje úplne bez automatiky, jednoducho správou:

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

Riadok o i-uzloch je potrebný zvlášť: dochádzajú nezávisle od miesta a bez neho táto situácia zostane nepovšimnutá.

Kontrola konfigurácie

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

monit -t overí syntax pred nasadením. monit summary dá krátku tabuľku stavov — od nej sa oplatí začínať rozbor akéhokoľvek problému.

A overte odosielanie pošty. Monit hlási udalosti listom, a ak odosielanie nie je nastavené, upozornenie nepríde — služba sa reštartuje, vy sa to nedozviete, a práve opakované reštarty sú hlavný signál. Vidieť ich možno aj v logu: /var/log/monit.log.

Čo Monit nerobí

Neodstraňuje príčinu. Reštart je odklad a neustále reštartovaná služba znamená, že niekde nestačí pamäť, dochádza miesto alebo tečie aplikácia. Hodnota nástroja nie je v samotnom reštarte, ale v počítadle: tri reštarty nginxu za deň sú diagnóza, ktorá by inak zostala nepovšimnutá, lebo web celý ten čas fungoval.

Preto treba pozerať nie na aktuálny stav (ten je takmer vždy zelený), ale na históriu: koľkokrát sa za týždeň niečo zdvihlo samo. Ako to vyzerá na jednej stránke, ukazuje ukážka nižšie.