JARVIS Panel: Monitorización Integral de Recursos y Estado de Servicios Críticos

Un servidor puede estar al 10 % de CPU y seguir siendo inútil: si el servicio de la aplicación responde con error 503, la máquina impecable no sirve para nada. La monitorización seria cubre las dos mitades —recursos y servicios— y añade la tercera que casi nadie tiene: respuesta automática cuando algo se cae. Esta guía describe cómo el Panel JARVIS vigila CPU, RAM y disco con psutil, verifica servicios con health checks y cierra el círculo con watchdog y autoreparación.

Verás qué métricas mirar de cada recurso —y cuáles no aportan—, cómo distinguir un servicio caído de uno que responde mal, y qué puede hacer el sistema solo antes de despertar a alguien. El contexto completo del panel está en Panel JARVIS y la arquitectura que lo sostiene, en Panel JARVIS. Nada de esto requiere agentes exóticos: Python y buenas definiciones de alerta.

Recursos: CPU, RAM y disco con psutil

La base es la colección de métricas en tiempo real, y en Python eso se hace con psutil, que expone el estado del sistema sin dependencias raras. Vigilar solo el porcentaje global de CPU es el error de siempre: lo útil es mirar la carga por núcleo y la cola de procesos listos, porque ahí se distingue un cuello de botella de procesamiento de uno de concurrencia. Con el porcentaje global solo, un proceso atascado en un núcleo puede pasar desapercibido.

Memoria: la que se nota en la experiencia

En RAM, el panel separa lo usado, lo libre y lo ocupado por caché —que el sistema puede devolver—, porque "85 % de uso" no significa lo mismo con caché abundante que con swapping activo. El swapping es la señal roja: cuando la memoria se va al disco, todo va lento y la app crítica paga la factura. Tres números en la portada bastan: uso real, swap activo y proceso que más consume.

Disco: espacio, IOPS y latencia

El disco es el que se ignora hasta el día del desastre. El panel vigila espacio libre, tasa de lectura/escritura (IOPS) y latencia: el espacio llena avisa con días de margen, y la latencia creciente con el mismo uso señala desgaste del medio antes de que falle. Y la correlación es lo que da el diagnóstico: un pico de CPU junto a latencia de disco alta apunta a E/S, no a falta de potencia; sin correlación, cada gráfico por separado solo dice que algo va mal.

Todo esto se recoge con baja latencia de reporte —métricas cada pocos segundos, no un muestreo por minuto— para que el panel no mida el pasado. Un sistema de monitorización que tarda dos minutos en decirte cómo está es un informe, no un panel.

Health check: ¿funciona el servicio de verdad?

Que el proceso esté vivo no significa que el servicio funcione. Un health check riguroso comprueba que responde a sus peticiones normales, que sus dependencias —base de datos, cola, API externa— están disponibles y que las transacciones de negocio fluyen. Si el endpoint devuelve 503 o la consulta base falla, el panel lo marca enseguida y con causa: servicio X, dependencia Y. Sin eso, la alerta es "algo va mal" y alguien pierde media hora mirando.

El error típico es el health check demasiado superficial: un ping al puerto abierto que sigue abierto aunque la aplicación no pueda completar una sola operación. Define el check como la operación mínima real —una lectura, un login simulado, una fila escrita— y hazlo cada pocos segundos. Ese mismo check es el que el watchdog y la autoreparación usarán después, así que merece la pena construirlo bien una vez.

Latencia, QoS y SLA

La latencia —cuánto tarda el servicio en responder— suele ser el primer indicador en moverse. Un aumento gradual, día tras día, con el servicio todavía "arriba", anuncia una degradación inminente: disco llenándose, pool de conexiones justo, memoria fuga. Medirla de forma constante y alertar sobre la tendencia, no solo sobre umbrales absolutos, permite intervenir antes de que el usuario final vea nada.

Con latencia y disponibilidad medidas, los acuerdos de nivel de servicio (SLA) dejan de ser fe: puedes demostrar cumplimiento y ver el margen que te queda cada mes. Y el diagnóstico cruzado completa el cuadro: si sube la latencia, el panel busca a la vez subidas de CPU o de cola de I/O y entrega la sospecha con datos, no con corazonadas.

Watchdog y autoreparación: cuando el sistema actúa solo

El watchdog supervisa la salud general y los procesos críticos por heartbeat: si un servicio vital deja de enviar señales —o el health check se cae tres veces seguidas—, declara fallo crítico y notifica al responsable con prioridad. Sin watchdog, un servicio muerto de madrugada puede pasar ocho horas sin que nadie se entere, y esas ocho horas son las que rompen el SLA.

La autoreparación va un paso más: no solo alerta, actúa. Ante el fallo confirmado, el panel puede reiniciar el servicio caído, redirigir el tráfico a un clúster secundario o pedir más recursos si detecta saturación puntual. Con reglas conservadoras —reintentos acotados, escalado a persona si dos intervenciones automáticas no bastan— se reduce mucho el tiempo medio de reparación (MTTR) sin el riesgo de un sistema que se reinicia en bucle sin diagnóstico.

Errores típicos y por dónde empezar

• Alertas sin contexto. "CPU al 90 %" un domingo con copia nocturna es ruido; incluye ventana horaria y causa probable o la alerta se ignora.
• Vigilar sin actuar. Si cada alerta termina en "lo miramos mañana", monta la autoreparación básica antes que la quinta métrica.
• Umbrales iguales para todo. La RAM al 70 % en desarrollo es normal; en producción con margen, es aviso. Cada servicio necesita su umbral.
• Olvidar el log del propio panel. Cada fallo, reinicio y corrección debe quedar registrado: es lo que permite afinar reglas y demostrar qué pasó.

El orden de implantación es recursos con psutil, después health checks reales, después latencia y alertas con dueño, y solo al final watchdog y autoreparación con reglas conservadoras. Cada capa añadida sin la anterior solo añade ruido. Con las cuatro, el panel pasa de enseñar gráficos a sostener la infraestructura: la vigila, avisa, actúa y deja registro de lo que hizo — que es exactamente lo que se espera de un sistema que no duerme.