🌐 También en: English · Deutsch · Français
Hora de confesarse. Hace un tiempo descubrí que fail2ban llevaba dos días muerto en mi servidor y yo sin enterarme. Un archivo de configuración apuntaba a una ruta de log que ya no existía, fail2ban se negaba a arrancar, systemd se encogía de hombros y todo aquello simplemente… se quedó ahí. Sin banear a nadie. En silencio. 🙈 Lo que da miedo no es que un servicio muriera: los servicios mueren. Lo que da miedo es que nada me avisó. Un control de seguridad puede fallar dejándolo todo abierto y no te enterarías hasta que fueras a mirar. Así que hice lo sensato y añadí un perro guardián cuyo único trabajo es darse cuenta de cuándo algo va mal y gritarme por ello.🤔 Por qué Monit (y no un script casero)
Mi primer instinto fue escribir un pequeño script en bash con un temporizador de cron. Luego recordé: esto es un problema resuelto, y reinventar la monitorización es la forma de acabar con un perro guardián que también falla en silencio. Hay herramientas consolidadas: Prometheus + Alertmanager (genial si ya vives en ese mundo), Icinga/Zabbix (excelentes, pero matar moscas a cañonazos para una máquina de andar por casa) y Monit, un demonio diminuto y especializado que hace exactamente una cosa bien: vigilar servicios y recursos, y avisar (o reiniciarlos automáticamente) cuando se portan mal. Monit ganó para un blog de nivel homelab por una razón por encima de todas: no solo avisa, también sabe curarse solo. Si fail2ban muere, Monit lo reinicia y me manda un correo. La caída de dos días habría sido un parpadeo de dos minutos con aviso incluido.📦 Requisitos e instalación
- AlmaLinux 9 con EPEL activado (ahí vive Monit):
dnf install monit, y tienes Monit 6.0. - Un relay de correo que funcione. Yo ya tenía
msmtpapuntando a mi proveedor para las alertas de rkhunter/ClamAV, así que Monit pudo reutilizar las mismas credenciales. - Root, porque comprueba servicios del sistema, el cortafuegos y el disco.
/etc/monitrc principal (ajustes del
demonio + relay de correo) y un archivo de comprobaciones en /etc/monit.d/.⚙️ Qué comprueba realmente
La filosofía: callado mientras todo esté sano. Monit solo manda correos ante un cambio de estado: algo sano empieza a fallar, o algo que fallaba se recupera. Una bandeja de entrada tranquila significa una máquina sana, así que un correo de Monit nunca es ruido.- 🥷 fail2ban, el invitado de honor. Reinicio automático vía systemd; si se niega a mantenerse en pie, Monit deja de insistir y envía en su lugar una alerta de «me rindo». El fallo exacto con el que empezó todo esto ahora se detectaría.
- 🔌 sshd, k3s, node_exporter, Prometheus, Grafana: alerta si la unidad de systemd no está activa.
- 🧱 Cortafuegos: no solo «¿está corriendo la unidad?», sino «¿está la cadena input de nftables de verdad en default-drop?». Un cortafuegos cargado pero vaciado es peor que inútil, así que compruebo lo que importa de verdad.
- 📦 Pods de K3s: cualquier cosa atascada en CrashLoopBackOff / ImagePullBackOff / OOMKilled / Error.
- 💽 Disco, carga, memoria: el aburrido tema de recursos que mata servidores en silencio a las 3 de la madrugada.
check process fail2ban with pidfile /run/fail2ban/fail2ban.pid
start program = "/usr/bin/systemctl start fail2ban"
if does not exist then restart
if 3 restarts within 5 cycles then timeout
check program firewall with path "/usr/local/sbin/monit-check-firewall.sh"
if status != 0 then alert📧 La trampa del correo (una buena hora de mi vida)
Esta es la parte que te va a ahorrar tiempo. Mi configuración demsmtp que funcionaba usaba STARTTLS en el puerto 587. Así que, naturalmente, configuré Monit de la misma
manera. Monit falló al instante con:Mail: Authentication failed -- no supported authentication methods foundusing
ssl significa SSL implícito, cuyo puerto estándar es el 465,
no el 587. En el 587 Monit hablaba en texto plano, el servidor no ofrecía AUTH antes de
STARTTLS (que nunca llegó a producirse) y Monit concluyó que «no había métodos de
autenticación soportados». 🤦 Para demostrar que el relay en sí estaba bien (y no perseguir a un fantasma), probé las
credenciales directamente con unas pocas líneas de Python smtplib:
en ambos puertos el inicio de sesión fue limpio y el servidor anunciaba AUTH PLAIN
LOGIN. O sea: relay bien, configuración de Monit mal. El arreglo fue una palabra y un
número:set mailserver smtp.example.com port 465
username "..." password "..."
using ssl🧪 Cómo lo probé (de forma honesta)
Un perro guardián al que nunca has oído ladrar no es más que decoración. Así que lo hice ladrar. Paré un servicio inofensivo y no crítico (node_exporter), forcé una
comprobación inmediata con monit validate en lugar de esperar al
siguiente ciclo, y me puse a mirar. Luego volví a arrancar el servicio para confirmar el
camino de recuperación. Esto es lo que llegó de verdad a mi bandeja de entrada: un
fallo, una recuperación y (de una segunda pasada) otro fallo:Monit on www.apt-upgrade.me reported:
Status failed: svc_node_exporter
at Tue, 28 Jul 2026 08:33:52
Action: alert
status failed (1) -- systemd service 'node_exporter' is inactive (expected: active)
-- Monit watchdogMonit on www.apt-upgrade.me reported:
Status succeeded: svc_node_exporter
at Tue, 28 Jul 2026 08:35:53
Action: alert
status succeeded (0) -- no output
-- Monit watchdogMonit on www.apt-upgrade.me reported:
Status failed: svc_node_exporter
at Tue, 28 Jul 2026 08:37:04
Action: alert
status failed (1) -- systemd service 'node_exporter' is inactive (expected: active)
-- Monit watchdog
