Midnightの監視エージェントがバリデータ障害を一分で検知

Midnightのデベロッパーリレーション担当であるStevan Lohjaが、九月二日のFireside Dev Hangで監視基盤を実演した。十三のバリデータのうち一つを意図的に停止すると、エージェントはおよそ一分以内に重大なイベントを報告し、ノードが何ブロック遅れているかを特定した。その後の一分間で復旧が自動的に確認された。

監視エージェントがインシデントをオペレーターに結び付ける

従来のテレメトリーは故障中のバリデータやサーバーを特定できるが、その情報だけでは運用者や対応すべき人物を判断できない。

この監視アーキテクチャは、バリデータとそのオペレーターを対応付けるロスターを用いる。あらかじめ定義された条件を満たすと、影響を受けたインフラを特定し、イベントの重大度を判断し、責任者をタグ付けし、関連する運用手順を添付する。

ライブテストでは、エージェントはそのバリデータがもはやデータを提供していないと報告し、イベントを重大と分類した。通知にはノードの遅延ブロック数が明記され、対応手順を記したrunbookへの参照が含まれていた。

バリデータが再起動すると、二通目のメッセージがインシデントの解消を示した。デモでの平均承認までの時間はおよそ一分だった。

重大アラートはAIモデルに依存しない

このアーキテクチャは、決定的なインシデント検知を言語モデルから切り離している。

監視ルールは、欠落したバリデータ、ファイナリティの問題、チェーンの分岐、接続ピア数の不足など、事前に定義された条件を監視する。時間しきい値により、通常の短時間のネットワーク変動が直ちに重大アラートを発生させないようにしている。

決定的なロジックが、イベントがインシデントに該当するかを判断し、重大度を割り当て、受信者を選定する。したがって、言語モデルが利用不能になった場合や無効な応答を出した場合でも、重大通知は稼働を継続できる。

小規模なローカルホストのモデルが、基礎となる技術データを可読なメッセージに変換する。これにより、イベントの説明、影響を受けたインフラの特定、適切な対応手順への接続が行われる。

Lohjaは、この構成のインフラコストを一月あたり約五十六ドルと見積もった。モデルはCPU上でローカル実行され、別途の商用推論料金を回避する。デプロイの管理にはTerraformを用い、公開インフラテンプレートは後日のリリースが予定されている。

Cardanoにおける潜在的ユースケースはガバナンスとハードフォークを対象とする

現在の本番デプロイはMidnightのバリデータインフラを監視している。セッションで議論されたCardanoのアプリケーションは、稼働中のサービスではなく提案段階の拡張にとどまっている。

一つのユースケースとして、非アクティブなDReps、引退したステークプール、そしてネットワークに参加していないオペレーターに委任が残っているケースを特定することが挙げられる。エージェントはそれらの記録を検証済みの連絡先情報と結び付け、ステータス確認を開始できる。

同様の手法で、ガバナンス提案、期限、投票しきい値を監視できる。投票を行っていない稼働中のステークプールを特定し、そのオペレーターに通知することも可能だ。ただし、信頼できる連絡先記録と誤った受信者に連絡しないための安全策が前提となる。

ハードフォークの調整も別の潜在的な応用先である。エージェントはソフトウェアの採用状況を追跡し、旧チェーンとアップグレード済みチェーンの活動を比較し、旧バージョンに留まっているピアを特定できる。

現在のデプロイをCardanoへ拡張するには、ガバナンスデータ、検証済みのオペレーター記録、そしてDReps、ステークプール、ネットワークアップグレードに特化した監視ルールが必要となる。