要約

  • LACNIC 46の発表資料は、14秒の回線断から原因判明まで約90分かかる想定例を示す。最初の苦情まで23分、手作業の診断にさらに67分という内訳だ。
  • 提案はsyslog、RouterOS v7、RADIUS、トポロジー情報をISP内に集約し、読み取り専用SQLを使うローカル言語モデルで検索する。

短い障害ほど、記録がなければ厄介だ。回線は14秒で戻っているのに、説明できる原因を見つけるまで90分。Joaquín Tadeo RiedmaierとSantiago Agustín ZualetがLACNIC 46のインターネット計測ワーキンググループ（IMWG）で示したのは、そんな時間のずれだった。資料の時系列では、最初の苦情が届くまで23分、その後ルーターを一台ずつ調べてログを絞り込む作業に67分かかる。

この時計は実測値ではない。発表資料は「重大事象の典型的な推定経路」とし、時刻も説明用としている。だが、問題の描き方は具体的だ。各ルーターにログが散り、再起動で失われ、無関係なイベントが原因を隠す。ネットワークは先に復旧しても、現場の担当者はその原因をまだ持っていない。

二人はミシオネス国立大学工学部に所属し、LACNIC 46・LACNOG 2026の会場で、複数の記録を一か所に集める設計を発表した。UDP syslogはリンク状態の変化、エラー、フラッピング、PPPoE/RADIUS切断を送る。RouterOS v7のREST APIはインターフェースやVLANごとの通信量、エラー、破棄、CPUとメモリー、ARP表、コネクショントラッキングを取得する。RADIUSのNAS別セッション状態を重ねれば、どの機器のどのポートが、どの加入者に波及したかを見比べられる。

構成はISP内のDockerノードを中心に組む。Djangoがsyslogを受け、APIを照会し、Pythonがノイズを除去してイベントを正規化・重複排除し、しきい値を判定する。PostgreSQLには検索用のビューを保存する。そこからローカル言語モデルが読み取り専用のSQLを作る。ビューを平坦化して結合を減らし、モデルのデータベース利用者をSELECTだけに絞る。発表資料は32GBメモリーの機器でモデルを試したと記すが、モデル名や処理負荷は示していない。

画面例では「過去4時間にどのルーターがリンク断を記録したか」と質問し、NAS 6のether2で7回の断があり、PPPoEセッション23件に影響したと答える。これは資料上、あくまで例だ。別の図は12時04分にL2/L3エラー、接続追跡、RADIUS、PPPoEの信号が重なったとし、物理リンク障害の可能性を示す。こちらもデータをシミュレーションした場面で、計測結果ではない。

提案の中で、しきい値通知と自然言語検索は別の役割を持つ。通知は苦情より先に短く知らせ、検索はその後の調査を助ける。モデルが担当するのは記録への入口だ。syslogが届かなければ、APIの取得間隔が14秒の障害を飛び越えれば、機器の時計がずれていれば、文章だけを整えても出来事の順序は戻らない。加入者情報との結合も含め、まず時刻の合ったデータが必要になる。

資料は90分を推定、18分を期待される効果と記し、ISPの障害サンプル、APIの取得間隔、導入前後の診断時間、誤報率、「95％以上」という目標の測定方法を示していない；これらを障害ごとに記録した試験結果が出れば、18分の評価は変わる。

この構想を次の段階へ進めるには、各障害について信号の到着、通知、担当者の着手、原因の確定を一本の時系列に残す必要がある。ネットワーク監視を会話形式に変えるだけでは不十分だ。散らばった記録を結び直し、調査にかかった時間を再現可能な形で短くできるか。18分の価値はその記録で決まる。

出典：LACNIC 46公式プログラム；IMWGの発表資料。