Monit pilnuje, żeby usługi działały, i podnosi je, kiedy padną. Pierwsze pytanie, jakie tu wypada zadać: po co to, skoro systemd potrafi to samo jednym wierszem Restart=always?

Odpowiedź wyznacza całą konfigurację. systemd widzi, że proces się zakończył, i uruchamia go ponownie. Nie wie natomiast, czy usługa odpowiada na żądania. PHP-FPM, który uderzył w limit procesów, jest dla systemd żywy i zdrowy, a witryna zwraca przy tym 502. MySQL, któremu skończyło się miejsce, nadal istnieje jako proces i nie wykonuje ani jednego zapytania. Monit sprawdza nie fakt istnienia procesu, lecz jego zachowanie: czy port odpowiada, co zwraca żądanie HTTP, ile zajęto pamięci.

Stąd zasada: systemd zostawiamy jak jest, a Monita dodajemy dla sprawdzeń funkcjonalnych. Powielanie restartu padniętego procesu nie ma sensu.

Konfiguracja

sudo apt install monit

Plik główny to /etc/monit/monitrc, własne sprawdzenia kładzie się osobnymi plikami w /etc/monit/conf.d/. Początek jest zwyczajny:

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

Odpytywanie raz na minutę to rozsądna równowaga. Częstsze dokłada obciążenia i podnosi ryzyko fałszywego restartu przy sekundowym opóźnieniu.

Interfejs webowy: tylko lokalnie

Monit ma wbudowaną stronę i domyślnie włącza się ją mniej więcej tak, jak pokazuje pierwszy lepszy poradnik — na wszystkich adresach. Powstaje panel sterowania usługami serwera dostępny z internetu. Właściwy wariant:

set httpd port 2812 and
    use address localhost
    allow localhost
    allow admin:'dlugie-haslo'

Dostęp z zewnątrz — przez tunel SSH:

ssh -L 2812:localhost:2812 user@203.0.113.25

Potem strona otwiera się na własnym komputerze pod adresem localhost:2812, a na zewnątrz nic nie wystaje.

Sprawdzenia, które mają sens

Serwer WWW — nie po fakcie istnienia procesu, lecz po odpowiedzi:

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

Trzy wiersze są tu ważniejsze od pozostałych.

protocol http ... status = 200 — to właśnie sprawdzenie, dla którego całą rzecz podejmowano: serwer ma zwrócić stronę, a nie tylko trzymać otwarty port.

for 3 cycles — nie reagować na pojedynczy błąd. Bez tego Monit zrestartuje usługę z powodu jednej wolnej odpowiedzi pod obciążeniem, czym tylko pogorszy sytuację.

if 3 restarts within 10 cycles then unmonitor — wiersz obowiązkowy. Jeśli usługa nie wstaje z powodu błędu w konfiguracji, Monit będzie ją restartował bez końca, dokładając obciążenia i zapełniając dzienniki. Ten wiersz znaczy: trzy nieudane próby — przerwać i zostawić komunikat. Dalej potrzebny jest człowiek, automat już nie pomoże.

Miejsce na dysku sprawdza się bez żadnej automatyki, samym komunikatem:

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

Wiersz o i-węzłach jest potrzebny osobno: kończą się niezależnie od miejsca i bez niego ta sytuacja pozostanie niezauważona.

Sprawdzenie konfiguracji

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

monit -t sprawdza składnię przed zastosowaniem. monit summary daje krótką tabelę stanów — od niej warto zaczynać rozbieranie każdego problemu.

I sprawdźmy wysyłanie poczty. Monit informuje o zdarzeniach listem, a jeśli wysyłka nie jest skonfigurowana, powiadomienia nie będzie — usługa się zrestartuje, my się o tym nie dowiemy, a właśnie powtarzające się restarty są głównym sygnałem. Widać je też w dzienniku: /var/log/monit.log.

Czego Monit nie robi

Nie usuwa przyczyny. Restart to odroczenie, a stale restartowana usługa oznacza, że gdzieś brakuje pamięci, kończy się miejsce albo cieknie aplikacja. Wartość narzędzia leży nie w samym restarcie, lecz w liczniku: trzy restarty nginksa na dobę to diagnoza, która inaczej pozostałaby niezauważona, bo witryna cały ten czas działała.

Dlatego patrzeć trzeba nie na stan bieżący (prawie zawsze zielony), lecz na historię: ile razy w tygodniu coś podniosło się samo. Jak to wygląda na jednej stronie, pokazuje demonstracja poniżej.