Monitorizar su servidor
Módulo 8: Copias de seguridad y monitorización · Tiempo de lectura: 10 minutos
Objetivo de aprendizaje: Tras esta lección sabrá decidir qué monitoriza de su servidor (desde fuera y desde dentro), qué umbrales tienen sentido y cómo conseguir que un aviso le llegue de verdad sin ahogarse en notificaciones.
Conceptos clave: monitorización desde fuera, monitorización desde dentro, uptime (tiempo en línea), comprobación http, comprobación de puertos, caducidad del certificado, espacio en disco, memoria, carga (load), heartbeat (dead man's switch), umbral, canal de avisos, fatiga de alertas, gráficas del proveedor
¿Por qué monitorizar?
Sin monitorización, se entera de los problemas por sus clientes, o no se entera en absoluto. Un sitio web caído desde el sábado, un certificado que caducó, un disco que se llenó, una copia de seguridad que lleva tres semanas fallando sin avisar: todo cosas que podría haber visto a tiempo. Monitorizar significa que un programa vigila de forma continua y le avisa cuando algo no va bien.
Una buena monitorización responde a dos preguntas:
- ¿Funciona para el usuario? Eso se mide desde fuera.
- ¿Va a fallar pronto? Eso se mide desde dentro: disco, memoria, actualizaciones, copias de seguridad.
Desde fuera: lo que ve el usuario
La monitorización desde fuera se ejecuta en una máquina distinta de su servidor, preferiblemente en otro proveedor. Es lógico: si su servidor está caído, ya no puede avisar por sí mismo.
| Comprobación | Qué hace | Por qué |
|---|---|---|
| http(s) | descarga una página cada minuto y comprueba el código de estado (200) y, si se desea, una palabra de la página | el sitio web funciona de verdad, no solo el servidor |
| puerto | se conecta, por ejemplo, al puerto 22 o 443 | el servicio escucha y es accesible |
| ping | envía un paquete ICMP | el servidor está vivo (pero no dice nada de su sitio web) |
| certificado | lee el certificado y su fecha de caducidad | avisa con suficiente antelación antes de que caduque |
| DNS | consulta el registro A | el nombre sigue apuntando al servidor correcto |
El certificado merece una atención especial. Los certificados de Let's Encrypt tienen una validez corta y se renuevan automáticamente (lección 7.3), pero si esa renovación falla sin avisar, solo lo notará cuando los visitantes reciban una advertencia. Desde junio de 2025, Let's Encrypt ya no envía correos recordatorios sobre certificados a punto de caducar, y recomienda usar monitorización. Una comprobación de certificado que avise cuando queden menos de 14 días de validez no es, por tanto, un lujo.
Un programa habitual para hacerlo usted mismo es Uptime Kuma, que instalará en un contenedor en la lección 9.4. En ese caso, es preferible no ponerlo en el mismo servidor que debe vigilar, o bien combinarlo con una segunda comprobación externa. También hay servicios de terceros que hacen lo mismo; elija uno que se adapte a usted y fíjese en dónde están establecidos si en los avisos pueden aparecer datos de sus clientes.
Desde dentro: lo que va a fallar pronto
Algunos problemas solo se ven desde fuera cuando ya es demasiado tarde. Esos se miden en el propio servidor:
| Qué | Cómo se ve | Un umbral razonable |
|---|---|---|
| Espacio en disco | df -h | advertencia por encima del 80%, alarma por encima del 90% |
| Inodos (número de archivos) | df -i | igual; un disco puede estar "lleno" con millones de archivos pequeños |
| Memoria | free -h, mensajes "Out of memory" en journalctl -k | cada mensaje OOM es una señal |
| Carga (load) | uptime, top | de forma prolongada por encima del número de vCPU |
| Servicios fallidos | systemctl --failed (lección 6.1) | cualquier servicio fallido |
| Actualizaciones y reinicio | /var/run/reboot-required, apt list --upgradable (lección 4.2) | actualización de seguridad pendiente desde hace más de dos días |
| Copias de seguridad | el final de su script de copia de seguridad (lección 8.2) | cualquier ejecución fallida o que no se haya producido |
Puede hacerlo con un script sencillo y un temporizador (lección 6.3) que envíe un aviso cuando se supere un umbral, o con un programa de monitorización con un agente en el servidor (ejemplos conocidos de código abierto son Netdata y la combinación de Prometheus con node_exporter). Empiece poco a poco: el disco, los servicios fallidos y las copias de seguridad cubren la mayoría de los problemas.
Las gráficas del panel de su proveedor (procesador, memoria, red y disco, desde un día hasta un año) son un buen complemento para ver tendencias: si su disco crece unos pocos puntos porcentuales cada mes, sabrá cuándo se llenará. En WebOké están en la pantalla del VPS; en otros proveedores, en un lugar similar. Normalmente no envían avisos, así que no sustituyen a la monitorización.
El heartbeat: avisar cuando no pasa nada
Algunas cosas hay que vigilarlas precisamente por la ausencia de una señal. La copia de seguridad de esta noche es el mejor ejemplo: si el script ni siquiera arranca (temporizador desactivado, servidor apagado, script roto), tampoco llega ningún mensaje de error.
La solución se llama heartbeat (latido) o dead man's switch: su monitorización espera una señal cada día. Al final, y solo si todo ha ido bien, el script de copia de seguridad envía una pequeña petición http a una URL fija y secreta de su monitorización:
restic backup ... && restic check && curl -fsS -m 10 https://status.example.com/api/push/Xyz123abc?status=up >/dev/nullSi un día no llega la señal, recibe un aviso. Uptime Kuma tiene para ello el tipo de monitor Push; también hay programas que puede alojar usted mismo, como Healthchecks. Así, con una sola línea, vigila si su copia de seguridad se ejecutó de verdad.
Avisos que llegan, y no demasiados
Un aviso que nadie lee no es monitorización. Organice tres cosas:
- Un canal de avisos que vea de verdad: una notificación push en su teléfono, un canal de chat, un SMS. El correo electrónico sirve, pero solo si su servidor puede enviar correo de forma fiable, y es fácil pasar un correo por alto. Para los avisos más importantes, use dos canales.
- Que no dependa de lo que vigila. Si es su propio servidor el que envía el correo sobre un disco lleno, ese correo no llegará cuando el disco esté lleno. La monitorización desde fuera y un heartbeat cubren ese caso.
- Pocos, pero justificados. Si recibe cada día diez avisos con los que no hace nada, acabará ignorándolos, incluido el que de verdad importa. Eso se llama fatiga de alertas. Ajuste los umbrales para que un aviso signifique: tiene que hacer algo. Haga que un aviso solo salte tras varias comprobaciones fallidas seguidas (por ejemplo, tres), para que un solo paquete perdido no le despierte.
Pruebe sus avisos: detenga un servicio un momento y compruebe si llega el aviso y cuánto tarda.
Lo que no debe hacer
- Páginas de monitorización abiertas a cualquiera con nombres y direcciones internas. Una página de estado pública está bien, pero muestre solo lo que los visitantes pueden saber.
- Una cuenta de administrador de su monitorización sin contraseña segura ni 2FA. Quien entre en su monitorización puede desactivar los avisos.
- Agentes con más permisos de los necesarios. Un agente de monitorización normalmente no necesita ser root.
Resumen
- Vigile desde fuera si todo funciona (http, puerto, certificado, DNS), desde otra máquina, y desde dentro si algo va a fallar pronto (disco, memoria, servicios, actualizaciones, copias de seguridad).
- Los certificados merecen su propia comprobación: desde junio de 2025, Let's Encrypt ya no envía correos recordatorios.
- Un heartbeat avisa cuando falta una señal; ideal para copias de seguridad y tareas programadas.
- Elija un canal de avisos que vea de verdad, independiente del propio servidor, y ajuste los umbrales para que cada aviso requiera una acción.
- Las gráficas de su proveedor muestran tendencias, pero normalmente no envían avisos.
Cuestionario
Ejercicio
Ejercicio O8.3: Su lista de supervisión. Elabore una lista de supervisión para su propio servidor: qué comprobaciones desde fuera (con qué intervalo y desde dónde), cuáles desde dentro (con umbrales), qué heartbeat(s) y por qué canal llegan los avisos. Configure al menos una comprobación externa de http o de certificado y un heartbeat (por ejemplo, para su copia de seguridad) y pruebe el aviso deteniendo un servicio un momento. Anote cuánto tardó en llegar el aviso.
Ejercicio O8.3: Su lista de supervisión
Este ejercicio lo hace usted mismo; nadie lo revisa. Marque lo que haya hecho y señale el ejercicio como realizado.
Comprobación desde fuera en otra máquina (preferiblemente de otro proveedor), cada 1 a 5 minutos con algunos reintentos. Certificado 14 días, disco 80/90%, systemctl --failed, heartbeat solo tras una copia de seguridad correcta. Avisos que no requieren ninguna acción: eliminarlos o subir el umbral.
Sus marcas y notas se quedan solo en este navegador; no las enviamos a ningún sitio. Si ha iniciado sesión, en Mis cursos solo guardamos que ha realizado el ejercicio.
Para saber más
- Sin acceso a su VPS: ¿qué hacer?
- Let's Encrypt, Expiration Notification Service Has Ended: https://letsencrypt.org/2025/06/26/expiration-notification-service-has-ended
- Uptime Kuma (GitHub): https://github.com/louislam/uptime-kuma
