摘要

  • LACNIC 46 的演讲用一段估算时序说明：链路中断14秒后，首次用户投诉可能要等23分钟，人工排查还需67分钟。
  • 提案在 ISP 本地汇聚 syslog、RouterOS v7、RADIUS 和拓扑数据，再让只读语言模型通过 SQL 查询整理后的记录。

14秒的断线已经恢复，工单却可能刚刚开始。LACNIC 46 的一页时间轴把这种错位写得很直白：首次投诉在23分钟后出现，人工诊断再花67分钟，直到约90分钟后才找到原因。讲者把它标为关键事件的“典型估算路线”，并注明时间仅供说明。14秒只占这90分钟的约0.26%。

这条时间轴来自 Joaquín Tadeo Riedmaier 和 Santiago Agustín Zualet 在 Mendoza 举行的 LACNIC 46 · LACNOG 2026 上所作演讲。两人来自 Universidad Nacional de Misiones 工程学院，在互联网测量工作组（IMWG）介绍了一个本地化监测方案。出发点不是让模型替 ISP 修线路，而是先把分散在路由器、接口和用户会话中的证据留在一处。

系统设计有两条采集路径。UDP syslog 主动推送链路状态变化、错误、抖动和 PPPoE/RADIUS 断连。RouterOS v7 的 REST API 按需读取接口与 VLAN 流量、错误与丢弃、CPU 和内存、ARP 表及连接跟踪；RADIUS 则补上 NAS 上的会话状态。这样，技术人员可以把某接口的 down/up 事件与同一时段的用户会话和拓扑位置并排查看。

提案把这些工作放在 ISP 自己的 Docker 节点内。Django 接收 syslog 并调用 API；Python 过滤噪声、规范化和去重事件，再检查阈值；PostgreSQL 保存用于查询的扁平视图。语言模型读取这些视图，通过只读数据库账户执行 SELECT。讲者称方案在32 GB 内存设备上测试过，但没有列出模型名称、测试负载或响应耗时。

演讲中的查询示例问过去四小时哪些路由器发生过 link-down。回答将 NAS 6 上 ether2 的七次记录与23个 PPPoE 会话联系起来。页面明确写着“示例”。另一个场景把 L2/L3 错误、连接跟踪、RADIUS 和 PPPoE 事件都放在12:04，然后推测 NAS 6 的物理链路故障；页面说明这是模拟数据，不是测量结果。它展示的是系统希望给出的答案形状，不是一次已记录的故障处理。

提案还把告警和调查分成两步：阈值先于投诉发出简短提醒，之后操作员再打开仪表盘，用自然语言追问。模型只是查数入口，不能替代数本身。若 syslog 未收到事件、API 采样间隔太长而错过14秒中断，或设备时钟对不上，流畅的文本也补不出缺失的顺序。数据采集的及时性、保留周期和会话关联仍决定答案能不能站住。

演讲把90分钟称为估算、把18分钟称为预期影响，却没有给出 ISP 现场事件样本、API 采样频率、前后测诊断时长、误报率或其“至少95%”目标的测试定义；逐事件公布这些指标的试点记录才会改变判断。

这项方案的价值在于指出时间究竟漏在哪里：故障信号散落各处，操作者要用经验把设备日志、用户会话和网络拓扑拼起来。集中采集和自然语言查询有机会减少这段手工拼接，但18分钟必须由现场记录证明。下一份演示应让人看见每个事件何时到达、哪条告警先触发、技术人员何时确认原因，而不是只看一张能回答问题的屏幕。

来源：LACNIC 46 官方议程；IMWG 原始演讲文件。