Health Checks y Monitoreo
Existen dos endpoints de health sin autenticación para monitores, más un dashboard de health de administración dentro de la app. Esta página explica qué reportan y cómo conectarlos al monitoreo.
GET /health: el chequeo completo
El endpoint de health de la propia instancia no es solo un ping. Ejecuta un conjunto de chequeos y reporta los resultados uno por uno:
- Alcance de la base de datos (crítico): el caso mayoritario de la respuesta "bad" del endpoint.
- Cordura del motor de plantillas (una compilación rápida de una plantilla de prueba).
- Memoria: el RSS del proceso se lee en Linux y se compara contra un umbral de 512 MiB (advertencia informativa cuando se supera).
- Chequeos adicionales cubren el entorno del script de build/salida; cada chequeo lleva su propio estado, detalle, severidad (critical/warning/info) y latencia medida.
La respuesta de nivel superior reporta status como critical si algún chequeo crítico falló, warning si solo se dispararon advertencias, y ok en caso contrario. Más un timestamp UTC, el número de chequeos, la lista por chequeo y un arreglo de warnings. Un monitor de uptime puede leer solo el campo status; un ingeniero de guardia obtiene la lista de chequeos.
GET /api/health: el resumen a nivel de site
Amigable para monitores de máquina: estado (ok o un estado de advertencia si el site tiene contenido pero nunca un build), conteo de páginas publicadas, timestamp del último build y si hay un build en progreso. Conecta este al chequeo de uptime externo.
El monitor cron de builds
El repositorio incluye un script cron listo (bin/cron-build-monitor.sh) diseñado para correr cada 5 minutos: monitorea que los builds completen con éxito y que las páginas existan en el árbol de salida (apunta al directorio de salida de la instancia vía la variable de entorno CHINASKI_OUTPUT). Prográmalo desde crontab tal cual o úsalo como plantilla para tu propio monitor.
Lo que pide la checklist de producción
La checklist de go-live del README pide exactamente este cableado: monitorear el endpoint de health (/health alcanzable desde tu monitor; 503 cuando la base de datos no es alcanzable), verificar que los backups corran a tiempo (systemctl list-timers chinaski-backup@<N> muestra un NEXT), y vigilar los logs basados en journal tras los cambios.