La ruta /status del portal D4R muestra el estado en tiempo real de todos los servicios del stack. La implementación usa un mecanismo pragmático: mientras Uptime Kuma no tiene monitores configurados, el portal sondea directamente los subdominios vía HTTP.
Cómo funciona probe_service
Cada servicio tiene un target con slug, name, subdomain y opcionalmente una path específica para el healthcheck. El portal lanza todos los sondeos en paralelo con asyncio.gather:
async def collect_status_snapshot(domain: str):
targets = status_targets_for_domain(domain)
services = await asyncio.gather(
*(asyncio.to_thread(probe_service, target) for target in targets)
)Cada probe registra el código HTTP recibido, la latencia en ms y el estado resultante (up si código < 500, down en caso contrario). El timeout por sonda es de 5 s.
Resolución de dominio dinámica
Los targets se generan en función del host de la petición entrante. Si el portal recibe una petición con host: d4r.es, los targets apuntan a *.d4r.es. Si el host es localhost, apuntan a *.localhost. Esto evita que un .env local contamine los enlaces de producción.
Plan de migración a Uptime Kuma
Uptime Kuma (ops-uptime-kuma-1) está desplegado y la base kuma.db existe, pero la tabla monitor tiene 0 filas. Cuando se configuren los monitores, el siguiente ajuste es cambiar la fuente de /status para leer de la API de Kuma en lugar de sondear directamente:
- Uptime Kuma expone una API JSON en
/api/status-page/heartbeat/{slug} - El portal puede agregar esos datos con el historial de uptime que Kuma mantiene
- Las alertas de Kuma pueden enviarse a n8n para notificaciones
Hasta entonces, los sondeos HTTP directos son suficientemente fiables para el uso actual del portal.
