Monit urmărește ca serviciile să funcționeze și le ridică atunci când cad. Prima întrebare potrivită aici: de ce asta, dacă systemd știe același lucru dintr-o singură linie Restart=always?

Răspunsul determină toată configurația. systemd vede că procesul s-a încheiat și îl pornește din nou. Nu știe dacă serviciul răspunde la cereri. Un PHP-FPM care a atins limita de procese este, pentru systemd, viu și sănătos, în timp ce site-ul returnează 502. Un MySQL căruia i s-a terminat spațiul continuă să existe ca proces și nu execută nicio interogare. Monit nu verifică existența procesului, ci comportamentul lui: răspunde portul, ce returnează o cerere HTTP, câtă memorie este ocupată.

De aici regula: systemd rămâne așa cum este, iar Monit se adaugă pentru verificările funcționale. Dublarea repornirii unui proces căzut nu are sens.

Configurare

sudo apt install monit

Fișierul principal este /etc/monit/monitrc, iar verificările proprii se pun ca fișiere separate în /etc/monit/conf.d/. Începutul este cel obișnuit:

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

O interogare pe minut este un echilibru rezonabil. Una mai deasă adaugă încărcare și crește riscul unei reporniri eronate din cauza unei întârzieri de o secundă.

Interfața web: doar local

Monit are o pagină web încorporată, iar implicit se activează cam așa cum arată primul ghid întâlnit — pe toate adresele. Rezultatul este un panou de control al serviciilor serverului, accesibil din internet. Varianta corectă:

set httpd port 2812 and
    use address localhost
    allow localhost
    allow admin:'parola-lunga'

Accesul din exterior printr-un tunel SSH:

ssh -L 2812:localhost:2812 user@203.0.113.25

După asta, pagina se deschide pe calculatorul tău la localhost:2812, iar în afară nu iese nimic.

Verificări care au sens

Serverul web — nu după existența procesului, ci după răspuns:

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

Trei linii sunt aici mai importante decât celelalte.

protocol http ... status = 200 — tocmai aceasta este verificarea pentru care s-a pornit totul: serverul trebuie să returneze o pagină, nu doar să țină un port deschis.

for 3 cycles — să nu reacționeze la o defecțiune izolată. Fără asta, Monit repornește serviciul din cauza unui singur răspuns lent sub încărcare, agravând situația.

if 3 restarts within 10 cycles then unmonitor — o linie obligatorie. Dacă serviciul nu se ridică din cauza unei erori de configurare, Monit îl va reporni la nesfârșit, adăugând încărcare și umplând jurnalele. Această linie înseamnă: trei încercări nereușite — oprește-te și lasă un mesaj. Mai departe este nevoie de un om, automatizarea nu mai ajută.

Spațiul pe disc se verifică fără nicio automatizare, doar printr-un mesaj:

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

Linia despre inode-uri este necesară separat: acestea se epuizează independent de spațiu, iar fără ea situația rămâne neobservată.

Verificarea configurației

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

monit -t verifică sintaxa înainte de aplicare. monit summary dă un tabel scurt de stări — cu el merită început analizarea oricărei probleme.

Și verifică trimiterea poștei. Monit anunță evenimentele prin scrisoare, iar dacă trimiterea nu este configurată, nu va exista nicio notificare — serviciul se repornește, tu nu afli, iar tocmai repornirile repetate sunt semnalul principal. Ele se văd și în jurnal: /var/log/monit.log.

Ce nu face Monit

Nu înlătură cauza. Repornirea este o amânare, iar un serviciu repornit permanent înseamnă că undeva nu ajunge memoria, se termină spațiul sau curge aplicația. Valoarea instrumentului nu stă în repornirea propriu-zisă, ci în contor: trei reporniri ale nginx într-o zi sunt un diagnostic care altfel ar fi rămas neobservat, pentru că site-ul a funcționat tot timpul.

De aceea trebuie privită nu starea curentă (aceasta este aproape întotdeauna verde), ci istoricul: de câte ori într-o săptămână s-a ridicat ceva singur. Cum arată asta pe o singură pagină arată demonstrația de mai jos.