Agente de Monitoramento da Midnight detecta falha de validador em um minuto

O representante de relações com desenvolvedores da Midnight, Stevan Lohja, demonstrou a infraestrutura de monitoramento durante o Fireside Dev Hang de 2 de setembro. Após um dos 13 validadores ser deliberadamente parado, o agente relatou um evento crítico em aproximadamente um minuto e identificou quantos blocos o nó havia ficado para trás. Sua recuperação foi automaticamente confirmada no minuto seguinte.

Agente de Monitoramento conecta incidentes com operadores

A telemetria convencional pode identificar um validador ou servidor com falhas, mas essa informação por si só não determina quem o opera ou quem deve responder.

A arquitetura de monitoramento usa um cadastro que mapeia validadores para seus operadores. Quando condições predefinidas são atendidas, ela identifica a infraestrutura afetada, determina a gravidade do evento, marca as pessoas responsáveis e anexa o procedimento operacional relevante.

Durante o teste ao vivo, o agente informou que o validador não estava mais fornecendo dados e classificou o evento como crítico. A notificação indicou quantos blocos o nó estava atrasado e fez referência ao runbook contendo as etapas de resposta.

Assim que o validador reiniciou, uma segunda mensagem marcou o incidente como resolvido. A demonstração produziu um tempo médio até o reconhecimento de aproximadamente um minuto.

Alertas críticos não dependem do modelo de IA

A arquitetura separa a detecção determinística de incidentes do modelo de linguagem.

Regras de monitoramento acompanham condições predefinidas, incluindo um validador ausente, problemas de finalidade, divergência de cadeia e um número insuficiente de pares conectados. Limiares de tempo impedem que mudanças comuns e de curta duração na rede gerem imediatamente alertas críticos.

A lógica determinística decide se um evento se qualifica como incidente, atribui sua gravidade e seleciona os destinatários. Assim, as notificações críticas podem continuar operando caso o modelo de linguagem fique indisponível ou produza uma resposta inválida.

Um modelo pequeno, hospedado localmente, converte os dados técnicos subjacentes em uma mensagem legível. Ele explica o evento, identifica a infraestrutura afetada e conecta a notificação ao procedimento de resposta apropriado.

Lohja estimou o custo de infraestrutura da configuração demonstrada em aproximadamente $56 por mês. O modelo roda localmente em uma CPU, evitando uma cobrança comercial de inferência separada. O Terraform é usado para gerenciar a implantação, enquanto modelos públicos de infraestrutura estão planejados para uma versão posterior.

Casos de uso potenciais em Cardano abrangem governança e hard forks

A implantação em produção atualmente monitora a infraestrutura de validadores da Midnight. As aplicações de Cardano discutidas durante a sessão permanecem extensões propostas em vez de serviços ativos.

Um caso de uso envolveria identificar DReps inativos, pools de stake aposentadas e delegações que permanecem atribuídas a operadores que não participam mais da rede. Um agente poderia conectar esses registros a informações de contato verificadas e iniciar uma verificação de status.

A mesma abordagem poderia monitorar propostas de governança, prazos e limiares de votação. Poderia identificar pools de stake ativas que não votaram e notificar seus operadores, sujeito a registros de contato confiáveis e salvaguardas contra contatar os destinatários errados.

A coordenação de hard forks oferece outra aplicação potencial. Um agente poderia acompanhar a adoção de software, comparar a atividade entre cadeias antigas e atualizadas e identificar pares que permanecem em uma versão anterior.

Expandir a implantação atual para Cardano exigiria dados de governança, registros de operadores verificados e regras de monitoramento projetadas especificamente para DReps, pools de stake e upgrades de rede.