Alertas de caída del sitio

Los gráficos del panel muestran el estado de la máquina, pero no responden a la pregunta «¿está el sitio en línea?». La aplicación puede colgarse mientras la CPU está inactiva, y sin una comprobación externa te enterarás por tus clientes.

Comprobaciones externas

La regla principal: no compruebes desde la máquina que estás monitorizando. Usa cualquier servicio externo de monitorización de uptime — hay muchos, incluidos planes gratuitos para varias direcciones con un intervalo de un minuto. Los ajustes que realmente importan:

• Dirección de comprobación. No la página de inicio, sino una ruta aparte como /healthz que compruebe tanto la base de datos como la cola. De lo contrario, se servirá una página de inicio en caché incluso cuando el backend esté muerto.
• Respuesta esperada. Un código 200 más una subcadena en el cuerpo. Muchas aplicaciones devuelven 200 con un mensaje de error cuando se rompen.
• Umbral. Dos o tres intentos fallidos seguidos, de lo contrario cualquier hipo de red te despertará.
• Canal. Telegram o correo electrónico. Asegúrate de que la alerta llega de verdad: desactiva el servicio durante un minuto y espera el mensaje.

No olvides una comprobación aparte de la caducidad del certificado — un certificado TLS caducado parece una caída y ocurre con regularidad.

Watchdog en la propia máquina

La monitorización externa te dirá que el sitio está caído. Para que vuelva a levantarse por sí solo, configura systemd. En la unidad del servicio:

[Service]
Restart=always
RestartSec=5
StartLimitBurst=5
StartLimitIntervalSec=120

Así el servicio sobrevivirá a una caída accidental, pero no entrará en un bucle infinito si la configuración está rota. Después de editar: systemctl daemon-reload && systemctl restart myapp.

Para las aplicaciones que no se caen pero se cuelgan, añade una comprobación HTTP. Un par de unidades — un timer y un servicio:

cat >/etc/systemd/system/healthcheck.service <<'EOF'
[Service]
Type=oneshot
ExecStart=/usr/local/bin/healthcheck.sh
EOF

cat >/etc/systemd/system/healthcheck.timer <<'EOF'
[Timer]
OnUnitActiveSec=60
[Install]
WantedBy=timers.target
EOF

systemctl enable --now healthcheck.timer

El propio script:

#!/bin/sh
curl -fsS --max-time 10 http://127.0.0.1:8080/healthz >/dev/null || systemctl restart myapp

Alertas de estado de la máquina

También es útil enterarse de que te quedas sin espacio en disco y sin memoria antes de una caída. La opción más sencilla es una tarea de cron que envíe un mensaje de Telegram cuando se supere un umbral:

0 * * * * root [ "$(df --output=pcent / | tr -dc 0-9)" -gt 85 ] && curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" -d chat_id=$CHAT -d text="VDS disk usage is over 85%"

Una opción más avanzada con umbrales ya preparados la ofrece Netdata.

Errores comunes

• Monitorizar en la misma máquina. Si la máquina se cae, tanto el watchdog como las alertas mueren.
• Un umbral demasiado sensible. Un chorro de falsas alarmas hace que pases de largo la de verdad.
• Restart=always en lugar de investigar la causa. Reiniciar enmascara una fuga de memoria: el servicio se cae cada media hora y tú no lo ves. Comprueba systemctl show myapp -p NRestarts y el journal.
• Comprobar solo con ping. La máquina responde a ICMP incluso con un servidor web completamente muerto.

Lo primero que hay que revisar cuando salta una alerta es «Overview» en el panel /hosting/vds/m/<id>. Un corte en los gráficos significa un problema con la máquina; unos gráficos planos cuando el sitio no está disponible significan un problema en la aplicación.