Monit holder øje med, at tjenester kører, og starter dem op, når de falder. Det første rimelige spørgsmål her: hvorfor dette, når systemd klarer det samme med linjen Restart=always?

Svaret bestemmer hele opsætningen. systemd ser, at processen er afsluttet, og starter den igen. Den ved ikke, om tjenesten svarer på forespørgsler. PHP-FPM, der har ramt procesgrænsen, er for systemd levende og rask, mens hjemmesiden svarer 502. MySQL, der er løbet tør for plads, findes stadig som proces og udfører ikke en eneste forespørgsel. Monit kontrollerer ikke, at processen findes, men hvordan den opfører sig: svarer porten, hvad returnerer en HTTP-forespørgsel, hvor meget hukommelse er optaget.

Deraf reglen: lad systemd være, som det er, og tilføj Monit til de funktionelle kontroller. At fordoble genstarten af en faldet proces er meningsløst.

Opsætning

sudo apt install monit

Hovedfilen er /etc/monit/monitrc, og egne kontroller lægges som separate filer i /etc/monit/conf.d/. Begyndelsen er det sædvanlige:

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

En forespørgsel i minuttet er en fornuftig balance. Hyppigere øger belastningen og risikoen for en fejlagtig genstart ved et sekunds forsinkelse.

Webgrænsefladen: kun lokalt

Monit har en indbygget webside, og som standard slås den til nogenlunde, som den første den bedste vejledning viser — på alle adresser. Resultatet er et kontrolpanel til serverens tjenester tilgængeligt fra internettet. Rigtig variant:

set httpd port 2812 and
    use address localhost
    allow localhost
    allow admin:'en-lang-adgangskode'

Adgang udefra går via en SSH-tunnel:

ssh -L 2812:localhost:2812 user@203.0.113.25

Derefter åbnes siden på din egen computer på localhost:2812, og intet stikker ud udadtil.

Kontroller der giver mening

Webserveren — ikke ud fra at processen findes, men ud fra 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 linjer her er vigtigere end de øvrige.

protocol http ... status = 200 — det er netop den kontrol, alt handlede om: serveren skal returnere en side, ikke blot holde en port åben.

for 3 cycles — reagér ikke på en enkeltstående fejl. Uden det genstarter Monit tjenesten på grund af ét enkelt langsomt svar under belastning, hvilket blot forværrer situationen.

if 3 restarts within 10 cycles then unmonitor — en obligatorisk linje. Kommer tjenesten ikke op på grund af en fejl i konfigurationen, vil Monit genstarte den i det uendelige, lægge belastning på og fylde logfilerne. Linjen betyder: tre mislykkede forsøg — stands og efterlad en meddelelse. Derefter kræves et menneske, automatikken hjælper ikke længere.

Diskplads kontrolleres helt uden automatik, blot med en meddelelse:

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

Linjen om inoder er nødvendig separat: de slipper op uafhængigt af pladsen, og uden den forbliver den situation ubemærket.

Kontrol af konfigurationen

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

monit -t kontrollerer syntaksen, før den tages i brug. monit summary giver en kort tabel over tilstande — der er det værd at begynde, når noget skal udredes.

Kontrollér også e-mailudsendelsen. Monit melder om hændelser med brev, og er udsendelsen ikke sat op, kommer der ingen advarsler — tjenesten genstartes, du får det ikke at vide, og det er netop gentagne genstarter, der er hovedsignalet. De ses også i logfilen: /var/log/monit.log.

Hvad Monit ikke gør

Det fjerner ikke årsagen. En genstart er en udsættelse, og en tjeneste, der konstant genstartes, betyder, at hukommelsen ikke rækker et sted, at pladsen slipper op, eller at applikationen lækker. Værktøjets værdi ligger ikke i genstarten, men i tælleren: tre genstarter af nginx i døgnet er en diagnose, der ellers ville være forblevet ubemærket, da hjemmesiden virkede hele tiden.

Derfor skal man se på historikken og ikke på den aktuelle tilstand (som næsten altid er grøn): hvor mange gange i løbet af ugen noget har rejst sig selv. Hvordan det ser ud på én side, viser demonstrationen nedenfor.