先给一个判断，它决定了整个技术选型的方向：WAN 链路质量是一个"路径上的时间序列问题"，而不是"设备的状态问题"。
这个判断一旦立住，很多设计问题就有答案了——为什么设备监控做满了还是发现不了链路劣化，为什么逐跳探测的结论经常是错的，为什么固定阈值在链路监控里基本没用。
下面按数据模型和判定逻辑拆一遍。
核心要点
- 监控对象是"路径"而不是"设备" ：链路质量不存在于任何单台设备的指标里，必须为"路径"单独建实体。
- 四类指标构成一个观测向量：延迟／抖动／丢包／可用性，缺任何一个都会误判。
- 逐跳结果不能直接采信：必须把反向验证规则做成可编程的判定函数。
- 阈值必须动态化：按"同链路 + 同时段"取基线，本质是把时间维度做进分组键。
- 探测调度是成本问题：分层频率 + 告警触发式加密采样，是唯一可扩展的组合。
一、为什么"设备模型"撑不起链路监控
传统监控的资源模型是"设备 + 端口"，指标挂在端口上。这套模型有两个天然缺口。
缺口一：链路不在实体里。 一条从 A 到 B 的路径，可能跨越多台设备、多个运营商、若干中间跳。它不属于 A 也不属于 B。你把 A、B 和所有中间设备的指标都采全了，依然没有一个对象来承载"这条路径的质量"。
缺口二：缺口正好是问题发生的地方。 链路劣化通常发生在"设备之间"或"运营商段"，这两处恰好是资源模型的盲区。这就是为什么设备全绿而用户喊慢。
所以要补一个实体：探测路径（probe path） ——由一对探测端点（源、目的）定义，四类质量指标挂在它上面，而不是挂在设备上。
二、数据模型：四个核心实体
| 实体 | 含义 | 关键字段 |
|---|---|---|
| 探测路径 | 一对端点定义的逻辑链路 | src_endpoint、dst_endpoint、direction、priority |
| 探测端点 | 具备主动探测能力的节点 | endpoint_id、site、clock_sync（NTP／PTP） |
| 测量样本 | 一次探测的结果 | path_id、ts、rtt、jitter、loss_pct、loss_cnt |
| 路径基线 | 按链路 + 时段聚合的统计基线 | path_id、hour_of_day、mean、stddev |
第三行有两个字段容易只留一个：loss_pct 和 loss_cnt 必须同时存。低流量链路上丢 1 个包就能算出很高的百分比，只看比率会误判为严重故障；只看绝对数又会漏掉高流量链路上的细微劣化。两个一起看才成立。
第四行的 hour_of_day 是设计上的关键——它把"时间"做进了分组键，后面算动态基线就自然成立。
三、判定逻辑：把经验做成函数
链路监控里最容易出错的是"判定"这一步，尤其是逐跳探测的结论。行业实践里比较一致的判定规则可以写成三段式：
| 判定输入 | 判定规则 | 结论 |
|---|---|---|
| 中间跳丢包高 + 末跳正常 | 末跳丢包远低于中间跳 | 中间设备限速，非真丢包 |
| 单方向劣化 | 双向指标不对称 | 路径不对称或单向策略 |
| ICMP 劣化 + TCP 正常 | 换协议后指标恢复 | ICMP 被限速 |
| 三条都不成立 | 末跳同向劣化 + 双向对称 + 换协议仍劣化 | 判定为真实链路劣化 |
这张表的工程意义在于：它把"老师傅的经验"变成了可测试的判定函数。每条规则都能写成断言，每条断言都能用历史数据回归验证。这比让值班的人凭感觉判断可靠得多。
还要注意一个不对称性：RTT 需要一台设备自计时，单向延迟需要两端时钟可比对。 从数据模型角度看，这意味着"探测端点"实体必须带一个 clock_sync 字段——没有它，单向数据在语义上就是不可信的，不能和 RTT 放进同一个分析口径。
四、基线：把时间做进分组键
固定阈值在链路监控里失效的原因很直白：链路的正常水位随时段变化。工作时段和凌晨的基线相差数倍，任何一个固定值都会在两端的某一端出错。
解法是把基线做成一个派生实体：按 路径 + 时段 分组聚合历史样本，得到均值和标准差，判定时用"当前值 vs 基线 + N 倍标准差"。
这里有两个设计权衡值得注意：
- 窗口长度。 太短会被单次波动带偏，太长则对趋势变化迟钝。覆盖 3–4 小时（15 分钟粒度约 12–16 个点）是个比较稳的区间。
- 分组维度。 业务有明显周期性的链路，还应该把"星期几"纳入分组，否则周末的基线会被工作日的样本污染。
五、探测调度：成本与时延的取舍
主动探测是要花成本的——带宽、设备 CPU、采集与存储。所以调度策略必须以"可扩展"为前提。
| 层级 | 频率 | 调度依据 |
|---|---|---|
| 核心路径 | 30 秒 | 承载业务数、商业影响面 |
| 次要路径 | 2 分钟 | 影响面中等 |
| 长尾路径 | 10 分钟 | 兜底覆盖 |
| 告警触发 | 临时切高频 | 命中基线偏离后自动加密采样 |
最后一行的设计特别值得推广：平时低频、出事加密。 它把成本压在常态、把采样密度集中在真正需要证据的时间窗里。相比"全量高频"，这在几百条路径的规模下几乎是唯一可行的方案。
另外要记得给探测流量单独限速。在本来就拥塞的链路上高频探测，会让监控自己成为拥堵源之一——这属于典型的"观测影响被观测对象"问题。
六、思考与总结
- 把"路径"建成一等公民。 设备模型不是错的，只是不够用。链路质量需要自己的实体来承载。
- 比率与绝对值必须同存。 这是链路数据里最常见的单字段陷阱。
- 判定规则要可编程、可回归。 把经验写成断言，才有办法验证它是否正确。
- 时钟同步是单向数据的语义前提。 没有它，单向延迟不是"精度差"，而是"不可信"。
- 调度策略的本质是成本约束下的采样密度分配。 平时低频、出事加密，是可扩展的核心思路。
如果只记一句：链路质量监控的难点不在采集，而在实体建模与判定逻辑。
参考来源
- IETF RFC 3393——IP 包延迟变化（抖动）度量指标
- IETF RFC 4656——单向主动测量协议（OWAMP）
一句话总结
把 WAN 链路质量建模为"路径上的时间序列"之后，设计就清晰了：新建"探测路径"实体承载四类指标，把反向验证规则做成可编程的判定函数，把时间做进基线的分组键，用分层频率加告警触发式采样来控制探测成本。
