L'agent de surveillance de Midnight détecte une panne de validateur en une minute
Un système de surveillance en production a détecté un validateur arrêté, a averti les opérateurs responsables et a confirmé son retour en service. La démonstration a aussi présenté des applications potentielles de Cardano couvrant l’activité de gouvernance et la coordination des hard forks.
By SongMarketCap
Le représentant des relations développeurs de Midnight, Stevan Lohja, a démontré l’infrastructure de surveillance lors du September 2 Fireside Dev Hang. Après l’arrêt volontaire de l’un des 13 validateurs, l’agent a signalé un événement critique en environ une minute et a indiqué de combien de blocs le nœud avait pris du retard. Son rétablissement a été confirmé automatiquement pendant la minute suivante.
L’agent de surveillance relie les incidents aux opérateurs
La télémétrie classique peut identifier un validateur ou un serveur en panne, mais cette information à elle seule ne détermine pas qui l’exploite ni qui doit intervenir.
L’architecture de surveillance utilise un répertoire qui fait correspondre les validateurs à leurs opérateurs. Lorsque des conditions prédéfinies sont réunies, elle identifie l’infrastructure concernée, détermine la gravité de l’événement, mentionne les personnes responsables et joint la procédure opérationnelle correspondante.
Lors du test en direct, l’agent a signalé que le validateur ne fournissait plus de données et a classé l’événement comme critique. La notification précisait de combien de blocs le nœud était en retard et renvoyait au runbook contenant les étapes de réponse.
Une fois le validateur redémarré, un second message a marqué l’incident comme résolu. La démonstration a produit un temps moyen de prise en compte d’environ une minute.
Les alertes critiques ne dépendent pas du modèle d’IA
L’architecture sépare la détection déterministe des incidents du modèle de langage.
Des règles de surveillance suivent des conditions prédéfinies, notamment un validateur manquant, des problèmes de finalité, une divergence de chaîne et un nombre insuffisant de pairs connectés. Des seuils temporels empêchent des changements réseau ordinaires et de courte durée de générer immédiatement des alertes critiques.
Une logique déterministe décide si un événement constitue un incident, lui attribue un niveau de gravité et sélectionne les destinataires. Les notifications critiques peuvent donc continuer à fonctionner si le modèle de langage devient indisponible ou produit une réponse invalide.
Un petit modèle hébergé localement convertit les données techniques de base en un message lisible. Il explique l’événement, identifie l’infrastructure concernée et relie la notification à la procédure de réponse appropriée.
Lohja a estimé le coût d’infrastructure de la configuration démontrée à environ $56 par mois. Le modèle s’exécute localement sur un CPU, évitant des frais d’inférence commerciaux distincts. Terraform est utilisé pour gérer le déploiement, tandis que des modèles d’infrastructure publics sont prévus pour une version ultérieure.
Des cas d’usage potentiels pour Cardano couvrent la gouvernance et les hard forks
Le déploiement de production surveille actuellement l’infrastructure des validateurs Midnight. Les applications Cardano discutées pendant la session restent des extensions proposées plutôt que des services actifs.
Un cas d’usage consisterait à identifier les DReps inactifs, les pools de staking retirés et les délégations qui restent attribuées à des opérateurs ne participant plus au réseau. Un agent pourrait relier ces enregistrements à des coordonnées vérifiées et lancer une vérification de statut.
La même approche pourrait surveiller les propositions de gouvernance, les échéances et les seuils de vote. Elle pourrait identifier des pools de staking actifs qui n’ont pas voté et avertir leurs opérateurs, sous réserve de registres de contact fiables et de garanties contre le fait de contacter de mauvais destinataires.
La coordination des hard forks constitue une autre application potentielle. Un agent pourrait suivre l’adoption logicielle, comparer l’activité entre les anciennes chaînes et celles mises à niveau et repérer des pairs qui restent sur une version antérieure.
L’extension du déploiement actuel à Cardano nécessiterait des données de gouvernance, des dossiers d’opérateurs vérifiés et des règles de surveillance conçues spécifiquement pour les DReps, les pools de staking et les mises à niveau du réseau.