El agente de supervisión de Midnight detecta una falla de validador en un minuto

El representante de relaciones con desarrolladores de Midnight, Stevan Lohja, demostró la infraestructura de monitoreo durante el Fireside Dev Hang del 2 de septiembre. Después de que uno de 13 validadores fuera detenido deliberadamente, el agente informó un evento crítico en aproximadamente un minuto e identificó cuántos bloques había quedado atrás el nodo. Su recuperación se confirmó automáticamente durante el minuto siguiente.

El agente de monitoreo conecta incidentes con operadores

La telemetría convencional puede identificar un validador o servidor con fallas, pero esa información por sí sola no determina quién lo opera ni quién debe responder.

La arquitectura de monitoreo utiliza una lista que asigna los validadores a sus operadores. Cuando se cumplen condiciones predefinidas, identifica la infraestructura afectada, determina la gravedad del evento, etiqueta a las personas responsables y adjunta el procedimiento operativo pertinente.

Durante la prueba en vivo, el agente informó que el validador ya no estaba proporcionando datos y clasificó el evento como crítico. La notificación indicó cuántos bloques tenía atrasado el nodo y remitió al runbook que contenía los pasos de respuesta.

Una vez que el validador se reinició, un segundo mensaje marcó el incidente como resuelto. La demostración arrojó un tiempo medio de reconocimiento de aproximadamente un minuto.

Las alertas críticas no dependen del modelo de IA

La arquitectura separa la detección determinista de incidentes del modelo de lenguaje.

Las reglas de monitoreo siguen condiciones predefinidas, incluido un validador ausente, problemas de finalidad, divergencia de cadenas y un número insuficiente de pares conectados. Umbrales de tiempo evitan que cambios ordinarios y de corta duración en la red generen de inmediato alertas críticas.

La lógica determinista decide si un evento califica como incidente, asigna su gravedad y selecciona a los destinatarios. Por lo tanto, las notificaciones críticas pueden seguir operando si el modelo de lenguaje deja de estar disponible o produce una respuesta no válida.

Un modelo pequeño, alojado localmente, convierte los datos técnicos subyacentes en un mensaje legible. Explica el evento, identifica la infraestructura afectada y vincula la notificación con el procedimiento de respuesta adecuado.

Lohja estimó el costo de infraestructura de la configuración demostrada en aproximadamente $56 por mes. El modelo se ejecuta localmente en una CPU, lo que evita un cargo comercial de inferencia por separado. Se utiliza Terraform para gestionar el despliegue, mientras que se planean plantillas públicas de infraestructura para una versión posterior.

Posibles casos de uso de Cardano abarcan la gobernanza y las bifurcaciones duras

El despliegue en producción actualmente monitorea la infraestructura de validadores de Midnight. Las aplicaciones de Cardano discutidas durante la sesión siguen siendo extensiones propuestas en lugar de servicios activos.

Un caso de uso implicaría identificar DReps inactivos, pools de stake retirados y delegaciones que permanecen asignadas a operadores que ya no participan en la red. Un agente podría vincular esos registros con información de contacto verificada e iniciar una verificación de estado.

El mismo enfoque podría monitorear propuestas de gobernanza, plazos y umbrales de votación. Podría identificar pools de stake activos que no han votado y notificar a sus operadores, sujeto a registros de contacto confiables y a salvaguardas contra contactar a destinatarios equivocados.

La coordinación de bifurcaciones duras ofrece otra aplicación potencial. Un agente podría rastrear la adopción de software, comparar la actividad entre cadenas antiguas y actualizadas e identificar pares que permanecen en una versión anterior.

Ampliar el despliegue actual a Cardano requeriría datos de gobernanza, registros de operadores verificados y reglas de monitoreo diseñadas específicamente para DReps, pools de stake y actualizaciones de red.