O Monit vigia que os serviços estejam a correr e levanta-os quando caem. A primeira pergunta legítima: para quê, se o systemd sabe fazer o mesmo com uma única linha Restart=always?

A resposta define toda a configuração. O systemd vê que um processo terminou e volta a iniciá-lo. Não sabe se o serviço responde aos pedidos. O PHP-FPM que atingiu o limite de processos está vivo e de boa saúde para o systemd, enquanto o sítio devolve 502. O MySQL sem espaço em disco continua a existir como processo e não executa uma única consulta. O Monit não verifica a existência de um processo mas o seu comportamento: se a porta responde, o que devolve um pedido HTTP, quanta memória está ocupada.

Daí a regra: o systemd fica como está, e o Monit acrescenta-se para as verificações funcionais. Duplicar o reinício de um processo caído não faz sentido.

Configuração

sudo apt install monit

O ficheiro principal é o /etc/monit/monitrc; as suas verificações vão como ficheiros separados para /etc/monit/conf.d/. O início habitual:

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

Um sondeio por minuto é um equilíbrio razoável. Mais vezes acrescenta carga e aumenta o risco de um reinício desnecessário por um segundo de atraso.

A interface web: só em local

O Monit traz uma página web integrada, e costuma ser ativada como mostra o primeiro guia que aparece: em todos os endereços. O resultado é um painel de comando dos serviços do servidor, alcançável a partir da internet. A variante correta:

set httpd port 2812 and
    use address localhost
    allow localhost
    allow admin:'uma-palavra-passe-longa'

O acesso a partir de fora passa por um túnel SSH:

ssh -L 2812:localhost:2812 user@203.0.113.25

Depois disso a página abre no seu próprio computador em localhost:2812, e para fora não fica exposto nada.

Verificações que fazem sentido

O servidor web, não pela existência de um processo mas pela sua resposta:

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

Três linhas ali importam mais do que o resto.

protocol http ... status = 200 é a verificação para que tudo isto foi montado: o servidor tem de devolver uma página, e não apenas manter uma porta aberta.

for 3 cycles significa não reagir a uma falha isolada. Sem isso o Monit reiniciará o serviço por causa de uma resposta lenta sob carga, o que só piora as coisas.

if 3 restarts within 10 cycles then unmonitor é uma linha obrigatória. Se um serviço não arranca por causa de um erro de configuração, o Monit reiniciá-lo-á sem fim, acrescentando carga e enchendo os registos. Essa linha significa: três tentativas falhadas, parar e deixar uma mensagem. A partir daí é preciso uma pessoa; o automatismo já não ajuda.

O espaço em disco verifica-se sem automatismo nenhum, apenas como aviso:

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

A linha dos inodes é precisa à parte: esgotam-se independentemente do espaço, e sem ela essa situação passa despercebida.

Verificar a configuração

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

monit -t verifica a sintaxe antes de aplicar. monit summary dá uma tabela breve de estados: o ponto de partida para analisar qualquer problema.

E verifique se o correio sai. O Monit comunica os eventos por correio, e se o envio não estiver configurado não haverá notificação nenhuma: o serviço reiniciará e você não saberá, quando reinícios repetidos são precisamente o sinal principal. Também se veem no registo: /var/log/monit.log.

O que o Monit não faz

Não elimina a causa. Um reinício é um adiamento, e um serviço reiniciado constantemente significa que em algum sítio falta memória, se esgota o espaço ou a aplicação tem uma fuga. O valor da ferramenta não está no reinício mas no contador: três reinícios do nginx num dia são um diagnóstico que de outro modo teria passado despercebido, porque o sítio funcionou todo o tempo.

Há portanto que olhar não para o estado atual — quase sempre verde — mas para o histórico: quantas vezes na última semana algo se levantou sozinho. Como fica numa página mostra-o a demonstração abaixo.