在阿里云上做 WAN 监控，和自建机房差别最大的是分支接入和跨地域互联：前者链路多、单条带宽小、现场常无人值守；后者的一段骨干由云平台托管，没有 SNMP 可轮询。这篇按阿里云的链路结构拆一遍：三层怎么分、每层怎么采。
核心要点
- 链路分三层：接入层（分支到云）、传输层（跨地域互联）、应用层（加速与负载均衡），可见性与责任方都不同。
- 分支接入的难点在规模：门店多、单条带宽小，探测频率必须分档。
- 路径分析与主动探测互补：前者回答走哪条路，后者回答路好不好走。
- 跨域边界要显式标注：托管段与自建段的归因方式完全不同。
- 成本天然可核算：账单按链路粒度出，配合质量数据可定位最该优化的链路。
一、三层链路结构
把链路按"谁负责、怎么采"拆成三层，后面的设计就顺了。
| 层 | 典型构成 | 采集方式 | 责任方 |
| 接入层 | 分支／门店 → 接入网关或专线／VPN → 云上接入点 | 设备状态 + 主动探测 | 自己 + 云平台 |
| 传输层 | 云企业网／转发路由器承载的跨地域互联 | 云侧连接状态 + 流量日志 | 云平台 |
| 应用层 | 全球加速、负载均衡、公网出口 | 实例指标 + 端到端探测 | 云平台 + 自己 |
这层划分的价值在于把"能自己查"和"只能提工单"分开：接入层问题大多能自己定位，传输层要靠云侧状态与工单，应用层两者交叉。
二、链路质量怎么采：三个数据源
云上采链路质量，靠单一数据源一定不够，可用的组合是三个。
数据源一：双向主动探测。在自建侧与云主机侧各部署探测端点互相打点。这是唯一能拿到端到端真实质量的方式——云平台不会替你测你和它之间那段路。
# 云主机侧对自建 IDC 探测点连续测量 ping -c 300 -i 0.2 203.0.113.10 | tail -5 mtr -rwzc 300 203.0.113.10 # 自建侧反向再测一次，用于双向对比 ping -c 300 -i 0.2 198.51.100.20 | tail -5 # 换 TCP 探测复核 ICMP 结论（排除限速假象） tcping -c 60 198.51.100.20 443
必须双向测的理由很实际：只有单方向数据，你无法区分是去程还是回程出了问题，而这个区分直接决定了该找谁。
数据源二：云侧路径分析能力。阿里云的网络智能服务类能力可以把流量五元组映射到实际转发路径，输出逐跳经过的转发设备与各段耗时。它回答"流量走在哪条路、哪一跳开始变慢"。
数据源三：云侧连接状态与流日志。跨地域连接、专线、VPN 的状态与流量数据，提供配置层的事实（连接通不通、规格多少）和流量层的证据（实际有多少流量走在上面）。
# 拉云侧连接清单与状态（以通用云 CLI 风格示意） cloudcli vpc describe-connections --output json > conns.json cloudcli vpn describe-vpn-gateways --output json > vpn.json cloudcli cbn describe-cen-attachments --output json > cen.json # 从流日志看实际路径（简化示例） SELECT srcaddr, dstaddr, dstport, COUNT(*) AS pkt FROM flow_log WHERE log_time > NOW() - INTERVAL '1 hour' GROUP BY srcaddr, dstaddr, dstport ORDER BY pkt DESC LIMIT 30;
三、分支接入场景：难点在规模
"总部 + 大量分支／门店"是阿里云上很典型的 WAN 场景，链路特征是数量多、单条带宽小、现场无人值守。这三个特征决定了三件事：
- 探测频率必须分档。几百个门店都用 5 秒一次，探测流量本身就很可观。核心门店高频、普通门店中频、长尾低频，被告警触发的才临时切高频。
- 要区分链路问题和门店内网问题。门店侧常见的"系统卡"，原因可能是内网交换机，也可能是出口链路。在出口内外各放一个探测点，两侧数据一比就能分开。
- 要能批量看、也能单点下钻。几百个门店不可能逐个看。合理视图是"健康度总表"，按异常程度排序，点进去再看该门店的链路详情。
四、从"哪一段慢"到"哪一跳慢"
这是云上最值得做的一步：主动探测发现某条路径劣化后，用路径分析把实际转发路径拉出来，看是哪一段或哪一跳开始异常。两者分工是——
- 主动探测回答"质量变差了没有、差多少"，给出延迟、抖动、丢包、可用性四类指标。
- 路径分析回答"走在哪条路上、在哪一段变差"，给出逐跳转发路径与分段耗时。
但要提醒一句：路径分析的结论不能直接采信。若某一跳显示异常、后续各跳和目标端都正常，更可能是那一跳对诊断报文做了限速。三条反向验证依然有效：末端同向劣化、双向对称、换协议仍劣化。
五、跨域边界：责任划分的前提
云上链路的责任边界比自建环境多：同一条门店到云上业务的路径，可能先后经过门店内网（自己）、接入链路（运营商）、云侧接入点（云平台）、跨地域传输（云平台）、云上应用层（自己配置）。
监控上必须把这些边界建成独立对象而非普通中间节点，好处有两个：一是可对跨边界链路单独设告警等级（影响面大、归因周期长）；二是提工单时能带上边界两侧的双向数据——只写"很慢"的工单处理周期往往很长，有两端数据责任切分才有共同依据。
六、成本核算：云上的顺手优势
云上带宽与专线账单天然按链路粒度出，省去了流量分摊的麻烦。把链路月费、平均利用率、质量指标放在一起，就能得出两类结论：月费高、利用率常年偏低的可考虑降配或迁移；月费不高但质量长期不达标的则要评估更换接入方式——一条便宜的烂链路，业务代价远高于省下的费用。
七、常见问题（FAQ）
Q1：阿里云上的专线、云企业网能用 SNMP 采链路质量吗？
通常不能。这些是云平台控制面的抽象对象，不暴露 SNMP 接口。能用 SNMP 的只有自建侧的路由交换设备和你部署在云主机上的软件。主流组合是"主动探测 + 云侧路径分析与连接状态"。
Q2：分支接入场景下探测点怎么布？
原则是"门店出口内外各一个、云上关键地域各一个"。出口内侧的点用于区分内网问题与链路问题，云上的点提供对比基准。门店很多时，可为每个地域选一个代表门店做高频探测，其余用低频兜底。
Q3：路径分析和主动探测结果不一致怎么办？
两者口径不同，不一致本身就是线索：主动探测测端到端体验，路径分析看流量实际经过哪里。若主动探测显示质量差、路径分析各段耗时正常，需检查三件事——探测与业务流量是否走同一条路径、是否存在路径不对称、应用或 DNS 层耗时是否被算进了"慢"。
Q4：跨地域互联的质量，云平台会提供吗？
云平台通常提供连接的可用状态和流量数据，但延迟、抖动这类细粒度质量指标往往不在标准监控里。建议在两端地域各部署探测端点做双向测量，这也是唯一能拿到该链路真实质量的方式。
参考来源
- IETF RFC 3393——IP 包延迟变化（抖动）度量指标
- IETF RFC 4656——单向主动测量协议（OWAMP）
- ME厂商实现文档（仅作技术对照，非推荐）
一句话总结
阿里云上做 WAN 监控的关键是"按层收口、按边界定责"：把链路拆成接入层、传输层、应用层，用双向主动探测、云侧路径分析、连接状态与流日志三个数据源覆盖，把跨域边界建成独立对象用于归因。
