Monit vigila que los servicios funcionen y los levanta cuando caen. La primera pregunta legítima: para qué, si systemd sabe hacer lo mismo con una sola línea Restart=always.

La respuesta define toda la configuración. systemd ve que un proceso ha terminado y lo lanza de nuevo. No sabe si el servicio responde a las peticiones. PHP-FPM que ha alcanzado su límite de procesos está vivo para systemd, mientras el sitio devuelve 502. MySQL sin espacio en disco sigue existiendo como proceso y no ejecuta ni una sola consulta. Monit no comprueba la existencia de un proceso sino su comportamiento: si el puerto responde, qué devuelve una petición HTTP, cuánta memoria hay ocupada.

De ahí la regla: systemd se queda como está y Monit se añade para las comprobaciones funcionales. Duplicar el reinicio de un proceso caído no tiene sentido.

Configuración

sudo apt install monit

El archivo principal es /etc/monit/monitrc; sus comprobaciones van como archivos aparte a /etc/monit/conf.d/. El comienzo habitual:

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

Un sondeo por minuto es un equilibrio razonable. Más a menudo añade carga y aumenta el riesgo de un reinicio innecesario por un segundo de demora.

La interfaz web: solo en local

Monit trae una página web integrada, y se suele activar tal como la muestra la primera guía que aparece: en todas las direcciones. El resultado es un panel de mando de los servicios del servidor, accesible desde internet. La variante correcta:

set httpd port 2812 and
    use address localhost
    allow localhost
    allow admin:'una-contrasena-larga'

El acceso desde fuera va por un túnel SSH:

ssh -L 2812:localhost:2812 user@203.0.113.25

Después, la página se abre en su propio ordenador en localhost:2812, y hacia fuera no queda expuesto nada.

Comprobaciones que tienen sentido

El servidor web, no por la existencia de un proceso sino por su respuesta:

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

Tres líneas ahí importan más que el resto.

protocol http ... status = 200 es la comprobación por la que se montó todo esto: el servidor debe devolver una página, y no solo mantener un puerto abierto.

for 3 cycles significa no reaccionar ante un fallo aislado. Sin eso, Monit reiniciará el servicio por una respuesta lenta bajo carga, lo que solo empeora las cosas.

if 3 restarts within 10 cycles then unmonitor es una línea obligatoria. Si un servicio no arranca por un error de configuración, Monit lo reiniciará sin fin, añadiendo carga y llenando los registros. Esa línea significa: tres intentos fallidos, parar y dejar un mensaje. A partir de ahí hace falta una persona; la automatización ya no ayuda.

El espacio en disco se comprueba sin automatismo alguno, simplemente como aviso:

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

La línea de los inodos hace falta aparte: se agotan con independencia del espacio, y sin ella esa situación pasa desapercibida.

Comprobar la configuración

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

monit -t comprueba la sintaxis antes de aplicarla. monit summary da una tabla breve de estados: el punto de partida para analizar cualquier problema.

Y compruebe que el correo sale. Monit informa de los eventos por correo, y si el envío no está configurado no habrá notificación: el servicio se reiniciará y usted no se enterará, cuando los reinicios repetidos son precisamente la señal principal. También se ven en el registro: /var/log/monit.log.

Lo que Monit no hace

No elimina la causa. Un reinicio es un aplazamiento, y un servicio que se reinicia constantemente significa que en algún sitio falta memoria, se acaba el espacio o la aplicación tiene una fuga. El valor de la herramienta no está en el reinicio sino en el contador: tres reinicios de nginx en un día son un diagnóstico que de otro modo habría pasado desapercibido, porque el sitio funcionó todo el tiempo.

Por eso hay que mirar no el estado actual —casi siempre verde— sino el histórico: cuántas veces en la última semana algo se levantó solo. Cómo se ve eso en una página lo muestra la demostración de abajo.