Monit passer på at tjenester kjører, og starter dem opp når de faller. Det første rimelige spørsmålet her: hvorfor dette, når systemd klarer det samme med linjen Restart=always?

Svaret bestemmer hele oppsettet. systemd ser at prosessen er avsluttet, og starter den igjen. Den vet ikke om tjenesten svarer på forespørsler. PHP-FPM som har truffet prosessgrensen, er for systemd levende og frisk, mens nettstedet svarer 502. MySQL som er tom for plass, finnes fortsatt som prosess og utfører ikke en eneste spørring. Monit kontrollerer ikke at prosessen finnes, men hvordan den oppfører seg: svarer porten, hva returnerer en HTTP-forespørsel, hvor mye minne er opptatt.

Derav regelen: la systemd være som det er, og legg til Monit for de funksjonelle kontrollene. Å doble omstarten av en falt prosess er meningsløst.

Oppsett

sudo apt install monit

Hovedfilen er /etc/monit/monitrc, og egne kontroller legges som separate filer i /etc/monit/conf.d/. Begynnelsen er det vanlige:

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

En spørring i minuttet er en fornuftig balanse. Hyppigere øker belastningen og risikoen for en feilaktig omstart ved et sekunds forsinkelse.

Webgrensesnittet: bare lokalt

Monit har en innebygd webside, og som standard slås den på omtrent slik den første beste veiledningen viser — på alle adresser. Resultatet er et kontrollpanel for serverens tjenester tilgjengelig fra internett. Riktig variant:

set httpd port 2812 and
    use address localhost
    allow localhost
    allow admin:'et-langt-passord'

Tilgang utenfra går via en SSH-tunnel:

ssh -L 2812:localhost:2812 user@203.0.113.25

Deretter åpnes siden på din egen maskin på localhost:2812, og ingenting stikker ut utover.

Kontroller som gir mening

Webserveren — ikke ut fra at prosessen finnes, men ut 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 viktigere enn de øvrige.

protocol http ... status = 200 — det er nettopp den kontrollen alt dreide seg om: serveren skal returnere en side, ikke bare holde en port åpen.

for 3 cycles — ikke reager på en enkeltstående feil. Uten det starter Monit tjenesten på nytt på grunn av ett eneste tregt svar under belastning, noe som bare forverrer situasjonen.

if 3 restarts within 10 cycles then unmonitor — en obligatorisk linje. Kommer tjenesten ikke opp på grunn av en feil i konfigurasjonen, vil Monit starte den på nytt i det uendelige, legge på belastning og fylle loggene. Linjen betyr: tre mislykkede forsøk — stopp og legg igjen en melding. Deretter trengs et menneske, automatikken hjelper ikke lenger.

Diskplass kontrolleres uten noen automatikk i det hele tatt, bare med en melding:

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

Linjen om inoder trengs separat: de tar slutt uavhengig av plassen, og uten den forblir den situasjonen ubemerket.

Kontroll av konfigurasjonen

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

monit -t kontrollerer syntaksen før den tas i bruk. monit summary gir en kort tabell over tilstander — der er det verdt å begynne når noe skal utredes.

Kontroller også e-postutsendingen. Monit melder om hendelser med brev, og er utsendingen ikke satt opp, kommer det ingen varsler — tjenesten startes på nytt, du får ikke vite det, og det er nettopp gjentatte omstarter som er hovedsignalet. De synes også i loggen: /var/log/monit.log.

Hva Monit ikke gjør

Det fjerner ikke årsaken. En omstart er en utsettelse, og en tjeneste som stadig startes på nytt, betyr at minnet ikke strekker til et sted, at plassen tar slutt, eller at applikasjonen lekker. Verktøyets verdi ligger ikke i omstarten, men i telleren: tre omstarter av nginx i døgnet er en diagnose som ellers ville forblitt ubemerket, siden nettstedet virket hele tiden.

Derfor skal man se på historikken og ikke på den aktuelle tilstanden (som nesten alltid er grønn): hvor mange ganger i løpet av uken noe har reist seg selv. Hvordan det ser ut på én side, viser demonstrasjonen nedenfor.