Monitoring en Sevastopol

Propósito

MonitoringViewIsland resume el estado de la plataforma en un dashboard ejecutivo único. Mezcla métricas de DB (tenants, usuarios, sesiones) con telemetría del host (CPU, RAM, disco, conexiones, errores).

Es complementario a herramientas de observabilidad continua — el SUPER_ADMIN abre esta vista al iniciar el día o cuando recibe alertas externas. No reemplaza Grafana ni paginators.

Decisiones de UX

Decisión	Motivo
Una sola llamada /api/monitoring	El Orchestrator consolida DB + systeminformation del host en un único payload. Evita N fetches paralelos en el frontend.
Sin auto-refresh	El operador refresca manualmente; los gauges no son tiempo-real. El monitoreo continuo vive en sistemas dedicados.
Tres KPIs como StatCard arriba	total_tenants, total_users, active_sessions — los tres números que el operador quiere ver primero.
Tres gauges grandes (CPU/RAM/Disco)	Cada uno con número grande coloreado + barra de progreso. Lectura visual a 3 metros.
Colores por umbral	< 50% verde, < 80% ámbar, ≥ 80% rojo. Estándar de salud del host.
Stats operacionales en grid secundario	Conexiones DB activas, errores API 24h, jobs fallidos 24h — métricas para diagnóstico, no para dashboard ejecutivo.
Sin acciones, solo lectura	El operador toma acción desde otras islands (sessions para kill, tenants para baja).

Datos visibles

Grupo	Campos esperados
KPIs de cuenta	total_tenants, active_tenants, total_users, active_sessions.
Salud del host	cpu_load_pct, memory_usage_pct, disk_usage_pct.
Operacionales	active_connections (DB), api_errors_last_24h, failed_jobs_last_24h.

Endpoints

Método + ruta	Uso
GET /api/monitoring	Consolidado de KPIs + system_health.

Backend de referencia

MonitoringService — agrega DB stats con systeminformation del host. Restringido a SUPER_ADMIN.