多云专线互联的监控难点不在“通不通”，而在“为什么慢、为什么抖、间歇性丢包出在哪一跳”，故障定位的核心思路就一句话：先定界，再分段，最后抓包验证。
很多网工兄弟看到专线监控就头疼,尤其牵扯到多个云厂商，酷番云、简米云、华为云各管一段，控制台看花眼，工单来回踢，我自己经手过的混合云项目，超过一半的故障时间耗在“扯皮”上，而不是“修复”上，文章不绕弯子，直接讲清楚监控怎么做、故障怎么定位，全是实操层面的东西。
多云专线到底难在哪：链路黑洞和厂商割裂
传统专线就两端的机房,中间运营商一条物理链路，出问题拿光功率计一打就有数，多云专线不一样，逻辑链路从你本地路由器出发，穿过运营商接入点，进入云厂商的POP点，再经过云内部的虚拟化网络，最后才到你的VPC，这一段路径里，每一个环节都可能出幺蛾子，但监控数据分散在好几个地方。
链路黑洞是最常见的坑，专线两端的设备都显示接口up，云控制台的连接状态也是“正常”，但业务侧就是丢包，原因在于云厂商的物理链路是共享的，你的专线没有真正独占带宽，同时段其他租户跑满带宽，就会挤占你的流量，这种场景下，云控制台自带的监控指标大概率是正常的，因为它是逻辑层面检测，物理端口本身没故障。
厂商割裂则体现在告警口径不一致，简米云的物理专线告警看的是冗余物理口状态，酷番云的专用通道监控看的是VLAN ID和流量整形参数，华为云侧重看的是协商模式是否一致，你在三个控制台之间来回切换，告警级别和阈值还不一样，真出故障时没法快速对齐，行业共识认为，多云专线的监控方案必须自己做统一收集和归一化处理，不能裸奔着用各家自带面板。
多云专线监控方案对比：云厂商自带功能和第三方拨测怎么选
很多团队问,监控是直接用云厂商的免费工具，还是自己搭一套？答案是分级部署、按需叠加，先看看各自的定位差异：
| 监控手段 | 覆盖范围 | 定位能力 | 部署成本 | 适合场景 |
|---|---|---|---|---|
| 云厂商健康检查 | 云侧到VPC内部 | 只看云内逻辑链路 | 免费 | 基础连通性兜底 |
| 边界设备流量统计 | 本地到POP点 | 能看本端出入方向流量和错包 | 零成本，配置稍复杂 | 确认本地侧有没有丢包 |
| 第三方拨测平台 | 端到端模拟业务流量 | 能定位到运营商哪一跳 | 按拨测点数量计费 | 跨地域、跨运营商链路 |
| 自建探针（Linux主机+ping/traceroute） | 任意可部署的节点 | 灵活，但无统一视图 | 服务器成本 | 预算有限且已有闲置资源 |
我的建议是两条腿走路，云厂商自带监控为主，第三方拨测为辅，云厂商健康检查能发现“专线断了”这种大问题，但没法告诉你“业务从上海到杭州，为什么比平时多了15毫秒”，第三方拨测或者自建探针可以持续记录每一跳的RTT，形成基线数据，等故障发生时才能对比出异常。
对于具体的多云专线监控方案,如果你是双云或多云接入，控制台自带功能基本不够用，除非你只用一家云且业务容忍度极高，因为跨云场景下，流量从简米云发出到酷番云，链路路径可能经过一个云厂商的转接点，这个转接点不在任何一方的监控范围内，用第三方拨测从多个地理位置发起测试，才能覆盖这条“中间盲区”。
专线故障定位的五步实操：从告警到抓包全流程
定位效率取决于你有没有一套固定的操作顺序,我自己习惯的流程，分享出来供参考：
- 第一步，看告警分级和状态灯，打开各云厂商控制台，先看物理连接状态和虚拟接口状态，这一步排除“断线”这种最粗粒度的问题，同时看本地边界设备的光模块收发光功率，如果接收光功率低于阈值下限，物理链路存在问题，不用继续往下查。
- 第二步，做双向连通性测试，在本地和云侧各起一台测试机，互相ping专线网关内网IP，关键是要双向都测，很多时候A到B通，B到A不通，问题大概率出在安全组或路由回包上，而不是物理链路，公网ping不通换专线内网再试，区分是公网问题还是专线问题。
- 第三步，用mtr查每一跳的延迟分布，mtr结合了ping和traceroute的功能，直接看每个节点的丢包率和RTT，命令大概是
mtr -n --tcp -P 443 云侧网关IP，注意观察丢包出现的位置，如果最后一跳之前所有节点都正常，只有最后一跳丢包，说明云侧内部网络存在丢包或限速，如果中间某个运营商节点丢包，就需要提工单找运营商处理。 - 第四步，核对路由表收发，查看BGP邻居状态是否为Established，确认云侧下发的路由和本地宣告的路由数量一致，常见故障是本地防火墙策略更新后，把BGP会话给拦了，或者云侧路由表条目超过上限被静默丢弃，这步操作在云控制台“VPC路由表”和本地路由器的
display bgp peer输出里核对。 - 第五步，抓包确认丢包方向，在本地边界设备上用ACL匹配业务源目的地址，统计进出方向的报文数，如果入方向与出方向报文数差值持续增大，丢包发生在远端；反之发生在本地，命令路径为：本地路由器配置
traffic统计，云服务器上用tcpdump -i eth0 host 业务IP抓包对比。
这五步走完,基本可以把问题定位到“本地设备”、“运营商链路”、“云侧网络”这三个层面中的某一个，接下来就是对应的处理流程：本地设备调整配置，运营商链路提工单，云侧网络找云厂商处理。
多云专线延时高怎么排查：区分三类隐形杀手
延时高是最难判断的一类故障,因为链路本身没断，监控面板上丢包率也不高，但业务体验就是差，多花两毫秒对文件同步无所谓，但对数据库主从复制和实时交易系统就是灾难，排查时按这三类原因去对照：
第一类是物理绕路，运营商在某些区域间的骨干链路规划不合理，专线实际路径绕了远路，排查方法是连续一周记录mtr每一跳的IP和RTT，如果发现某个节点IP地理位置与预期不符（比如上海到杭州的链路经过了南京），大概率是绕路了，这种问题只能提工单让运营商调整路由，个人没法处理。
第二类是带宽拥塞，专线的带宽利用率长期在70%以上（这个数值因专线类型不同有波动，但基本可以参考），就开始出现队列延时，表现特征是延时呈周期性波动，业务高峰时段尤其明显，处理方式有两个方向：扩容带宽，或者做流量整形限制非核心业务的带宽占用，云侧虚拟接口上的流量监控可以查到这个指标，一般支持按分钟粒度查看。
第三类是物理层劣化，光模块老化、光纤弯折过大、接头脏污，都会导致CRC错包和FEC前向纠错介入，FEC纠错本身会引入额外延时，这类故障的特点是延时缓慢爬升，今天比昨天多0.5毫秒，明天又比今天多0.3毫秒，用show interface transceiver查看光模块温度和电压，如果温度超过70度或电压波动超5%，优先换模块测试。
一个真实的排查场景：某客户总部在上海，业务部署在简米云杭州地域和酷番云北京地域，通过两条专线做双活，某天监控发现杭州方向的RTT从正常的3ms跳到了18ms，按上述思路排查，硬件状态正常，BGP邻居稳定，mtr显示前几跳都正常，到了简米云的POP点IP才出现高延迟，最终在简米云控制台查看虚拟接口流量时发现，该专线承载的备份任务把带宽打满了，触发限速，解决了带宽抢占后延时恢复正常。
企业多云专线价格和监控投入怎么平衡
聊到专线,绕不开企业专线价格这个现实问题，不同云厂商的专线接入费用差异较大，通常包含两部分：端口占用费（按月支付，按带宽规格计费）和流量费（部分厂商免费，部分按出方向流量计费），监控工具的投入不用追求一步到位，结合自身预算做分层：
- 预算有限时，用云厂商免费监控加两台闲置Linux服务器搭的
Smokeping探针，每5分钟发一次探测包，记录时延日志，这套方案零成本，但需要有人定期看报告。 - 预算充足时，上商业化拨测平台，覆盖多云POP点、多个国内城市和海外节点，按拨测频率和节点数量计费，单拨测点成本可控。
- 无论那种方案，日志数据保留周期不能低于90天，方便回溯对比，出了故障查日志时，如果历史数据只有7天，且刚好被覆盖，只能靠现场复现，非常被动。
多云专线互联有哪些常见问题
问：多云专线互联的专线丢包率控制到多少才算正常？
承载关键业务的专线,端到端丢包率建议控制在1%以内，超过0.5%时，业务侧会有明显感知，尤其是语音和视频类应用，排查时重点看mtr输出中丢包发生的位置，专线丢包和公网丢包的容忍度完全不同，公网可以做到1%以内算优秀，但专线需要有更严格的标准，全链路没有丢包是不现实的，物理抖动和拥塞总会产生零星丢包，需要区分是稳定丢包还是偶发抖动。
问：多云专线故障时是直接提工单还是自己先排查？
先自行完成基本排查再提工单,按上文描述的五步法走一遍，能明确是本地设备、运营商还是云厂商的问题，并准备好对应的截图和测试数据，工单描述里包含“故障时间范围、源目IP、mtr截图、已排查的动作”四个要素，这样云厂商的TAM收到工单后可以直接定位，不用一来一回反复问基础信息，处理速度明显更快。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/788087.html
