💓 Healthcheck simple: avisa si un servicio cae

por
Shared post

Antes de montar alertmanagers, un healthcheck en cron ya te avisa de caídas evidentes.

Más allá del comando suelto, lo importante es el contexto: cuándo aplicarlo, cómo validar el resultado y qué efectos secundarios puede tener en producción.

A continuación verás el porqué, ejemplos concretos con explicación, un flujo paso a paso, errores típicos y buenas prácticas para usarlo con confianza.

💡 Qué comprobar

  • HTTP 200 en un health endpoint
  • Puerto escuchando
  • Proceso esperado activo
  • Tener un procedimiento repetible reduce el tiempo de incidente
  • Documentar el enfoque ayuda al resto del equipo a operar igual de bien

🚀 Comandos y ejemplos

HTTP check:

#!/usr/bin/env bash
set -euo pipefail
code=$(curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1/health || true)
if [[ "$code" != "200" ]]; then
  echo "$(date -Is) FAIL code=$code" >>/var/log/health.log
  exit 1
fi

Adapta este ejemplo a tus paths y nombres reales antes de usarlo en producción.

Puerto abierto:

ss -lnt | grep ':443 '

Adapta este ejemplo a tus paths y nombres reales antes de usarlo en producción.

Comprobar proceso:

pgrep -a nginx || echo "nginx no está"

Complementa el check HTTP: a veces el puerto responde pero el binario no es el esperado.

Cron del healthcheck:

*/5 * * * * /usr/local/bin/healthcheck.sh

Cada 5 minutos suele bastar para servicios web simples.

🔧 Ejemplo práctico paso a paso

1. Define qué es “sano”

Ejemplo: http://127.0.0.1/health debe devolver 200. Si usas reverse proxy, decide si mides local (backend) o público (nginx+app).

2. Escribe el script con log de fallo

#!/usr/bin/env bash
set -euo pipefail
url=http://127.0.0.1/health
code=$(curl -s -o /tmp/health.body -w "%{http_code}" --max-time 5 "$url" || echo 000)
if [[ "$code" != "200" ]]; then
  echo "$(date -Is) FAIL code=$code body=$(head -c 200 /tmp/health.body)" >>/var/log/health.log
  exit 1
fi

3. Prueba a mano tumblando el servicio

Con la app up: el script sale 0. Haz sudo systemctl stop myapp (en staging) y confirma FAIL en el log. Arranca de nuevo.

4. Programa cada 5 minutos y alerta

Cron o systemd timer. En fase 2, envía mail/Slack solo en transición OK→FAIL para no spamear.

⚠️ Errores frecuentes

Comprobar solo que el puerto está abierto. Nginx puede servir 502 con el puerto 443 vivo. Mejor HTTP status + cuerpo mínimo.

Alertar en cada fallo sin debounce. Un blip de 1 segundo genera 100 pings. Alerta por cambio de estado o N fallos seguidos.

Healthcheck remoto caro cada 10s. Desde fuera y muy frecuente puedes crear carga o rate limits. Interno y ligero primero.

💡 Buenas prácticas

  1. Loguea éxitos de vez en cuando, no solo fallos.
  2. Evita alertar en bucle: backoff o flapping simple.
  3. El check debe ser barato y local cuando sea posible.
  4. Prefiere cambios reversibles y con rollback claro.
  5. Corrrelaciona siempre con logs y, si puedes, con una métrica simple.
  6. Si el procedimiento se repite, conviértelo en script versionado.

📝 Conclusión

Un healthcheck tonto y fiable detecta muchos incidentes antes que tus usuarios.

Si practicas este flujo con calma en staging, en producción te saldrá casi automático. Guarda tus variantes locales (paths, unidades, convenciones del equipo) junto a estos ejemplos.


Shared post