Monit ser till att tjänster körs och startar upp dem när de faller. Den första rimliga frågan här: varför detta, när systemd klarar samma sak med raden Restart=always?

Svaret bestämmer hela uppsättningen. systemd ser att processen avslutats och startar den igen. Den vet inte om tjänsten svarar på förfrågningar. PHP-FPM som slagit i processgränsen är för systemd levande och frisk, medan sajten svarar 502. MySQL som fått slut på utrymme fortsätter finnas som process och utför inte en enda fråga. Monit kontrollerar inte att processen existerar utan hur den beter sig: svarar porten, vad returnerar en HTTP-förfrågan, hur mycket minne är upptaget.

Därav regeln: låt systemd vara som det är och lägg till Monit för de funktionella kontrollerna. Att dubblera omstarten av en fallen process är meningslöst.

Uppsättning

sudo apt install monit

Huvudfilen är /etc/monit/monitrc, och egna kontroller läggs som separata filer i /etc/monit/conf.d/. Början är det vanliga:

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

En avfrågning per minut är en rimlig balans. Tätare ökar belastningen och risken för en felaktig omstart vid en sekunds fördröjning.

Webbgränssnittet: bara lokalt

Monit har en inbyggd webbsida, och som standard slås den på ungefär så som den första bästa guiden visar — på alla adresser. Resultatet är en kontrollpanel för serverns tjänster tillgänglig från internet. Rätt variant:

set httpd port 2812 and
    use address localhost
    allow localhost
    allow admin:'ett-langt-losenord'

Åtkomst utifrån går via en SSH-tunnel:

ssh -L 2812:localhost:2812 user@203.0.113.25

Därefter öppnas sidan på din egen dator på localhost:2812, och ingenting sticker ut utåt.

Kontroller som är meningsfulla

Webbservern — inte utifrån att processen finns, utan utifrån svaret:

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

Tre rader här är viktigare än de övriga.

protocol http ... status = 200 — det är just den kontroll allt handlade om: servern ska returnera en sida, inte bara hålla en port öppen.

for 3 cycles — reagera inte på ett enstaka fel. Utan det startar Monit om tjänsten på grund av ett enda långsamt svar under belastning, vilket bara förvärrar läget.

if 3 restarts within 10 cycles then unmonitor — en obligatorisk rad. Kommer tjänsten inte upp på grund av ett konfigurationsfel startar Monit om den i all oändlighet, lägger på belastning och fyller loggarna. Raden betyder: tre misslyckade försök — sluta och lämna ett meddelande. Därefter behövs en människa, automatiken hjälper inte längre.

Diskutrymme kontrolleras utan någon automatik alls, bara med ett meddelande:

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

Raden om inoder behövs separat: de tar slut oberoende av utrymmet, och utan den förblir det läget obemärkt.

Kontroll av konfigurationen

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

monit -t kontrollerar syntaxen före tillämpningen. monit summary ger en kort tabell över tillstånd — där är det värt att börja när något ska redas ut.

Kontrollera också e-postutskicket. Monit meddelar om händelser med brev, och är utskicket inte inställt kommer inget larm — tjänsten startas om, du får inte veta det, och det är just upprepade omstarter som är den viktigaste signalen. De syns även i loggen: /var/log/monit.log.

Vad Monit inte gör

Det åtgärdar inte orsaken. En omstart är ett uppskov, och en tjänst som ständigt startas om betyder att minnet inte räcker någonstans, att utrymmet tar slut eller att applikationen läcker. Verktygets värde ligger inte i omstarten utan i räknaren: tre omstarter av nginx på ett dygn är en diagnos som annars förblivit obemärkt, eftersom sajten fungerade hela tiden.

Därför ska man titta på historiken och inte på det aktuella tillståndet (som nästan alltid är grönt): hur många gånger under veckan något rest sig själv. Hur det ser ut på en sida visar demonstrationen nedan.