Summary

  • WLCG/OSG 的 perfSONAR 网格覆盖 170 多个站点、每天约 400 万次测试；工具把每条走廊上的路径变化与性能数据对齐。
  • 海缆故障期间，紧急路径把时延降了一半，吞吐量却崩了。四种结果分类把“路由变了”与“服务受损”分开。

Traceroute 像一张路线明信片：它告诉你测试那一刻，数据包从哪里经过。路线变了，当然值得看；但这还不是性能诊断。海缆可能故障，流量可能绕路，应用仍能满速传输；也可能新路线看起来更快，数据传输却垮了。地图和服务得一起读。

10 月 26 日，Petya Vasileva 在 RIPE 93 介绍了一种面向科研与教育网络的做法。WLCG/OSG 的 perfSONAR 网格连接 170 多个站点，每天运行约 400 万次测试。工具先为每条源到目的地的走廊建立近期路径基线；路线发生变化时，再把它与时延、丢包和吞吐量测量对齐。

这些测量回答的是不同问题。Traceroute 描述观测到的路径；OWAMP 可以测单向时延与丢包；iperf3 则由 pScheduler 安排，用于测吞吐量。perfSONAR 的官方文档把它们列为不同测试类型，原因很实际：路由改变不一定影响服务，而性能指标变化也可能不是路径快照能解释的。

工具把每条走廊归入四种面向运维的结果：确认有影响、路径改变但没有可测影响、测试中断、需要复核。NOC 因此拿到一张有顺序的调查清单。它不会把每条变过的路由都塞到队首，再叫值班人员解释图表为什么闪了一下。

海缆故障案例就是标题里的反转。紧急路径把时延降了一半，吞吐量却崩了。只盯延迟的仪表盘可能一边报喜，一边让大型数据传输窒息。路径变快了，工作没变快。工具把路径变化和性能记录放在一起，才看见这两个事实互相打架。

另一例追踪了数月间歇性的低水平丢包。共享路径证据把问题收敛到一个站点的入口设备。这不如全网告警戏剧化，却能把“偶尔很慢”缩到运维人员能检查的地方。RIPE NCC 的会议记录提到英国走廊出现明显丢包，包括 AMS–LON 海缆故障，并请 NOC 与 NREN 分享事件记录。事件记录能把测量曲线和运维现场发生的事接起来。

这套方法使用现有 perfSONAR 测量。RIPE 表示它不需要 BGP 数据流、不增加探针，也不需要带标签的训练数据。诊断因此贴近已经在监看走廊的仪器。ESnet 的 Science DMZ 指南也采用类似的分工：持续检查时延和丢包，定期跑吞吐量测试，再由网络工程师排查路由和交换设备。

四种分类比一个红点更有用，因为它说明证据能支持什么。“路线变了”是一条观察；“确认有影响”则是由对齐测量支持的判断。“测试中断”说明测量系统自己失去了视线；“需要复核”让问题留在队列里，却不假装已有结论。每个标签都该带出下一个问题，而不是只制造告警声。

最终裁判是正在运行的网络。换路可能对服务没有影响；时延降低可能同时伴随吞吐崩塌；反复丢包可能只在一处入口，而非整条走廊。把路径、时延、丢包和吞吐量放到同一条时间线上，NOC 才能处理用户感受到的故障，而不是追着最显眼的图表跑。公开材料没有列出各分类的误报率；这张表能说明“确认有影响”到底有多可信。

Sources: RIPE 93 演讲与摘要；RIPE NCC 10 月 26 日会议记录；ESnet Science DMZ 测量指南；perfSONAR 测试文档。