SD-WAN 监控看哪些指标？
简答：SD-WAN 监控优先看五层：链路质量、隧道健康、设备资源、路由控制面和应用体验。日常面板至少包含延迟、丢包、抖动、带宽利用率、隧道状态、CPU/内存、路径切换和应用响应时间，再按“链路→隧道→设备→应用”顺序定位异常。
定义：SD-WAN 监控是对底层 WAN 链路、加密隧道、边缘设备、路由控制面和业务应用体验进行持续采集、对比与告警的运维方法。
先看这张表：SD-WAN 监控优先级怎么排
如果刚开始建设监控面板，不要一次加入所有字段。先覆盖能直接回答“哪里坏了、影响谁、是否正在恢复”的指标，再补充容量趋势和应用体验。不同厂商的字段名称、采样周期和健康算法可能不同，以下是跨平台的监控框架，不是统一行业阈值。
| 层级 | 优先指标 | 主要回答的问题 | 异常时先查什么 |
|---|---|---|---|
| 底层链路 | 接口状态、往返时延、丢包、抖动、带宽利用率、接口错误 | 运营商线路或本地出口是否异常 | 接口、物理链路、上行设备和运营商侧 |
| 隧道与路径 | 隧道 UP/DOWN、隧道时延、丢包、抖动、路径切换次数 | Overlay 是否健康，选路是否频繁变化 | 隧道建立、探针、加密端点和路径策略 |
| 设备资源 | CPU、内存、温度、会话数、接口收发速率 | 设备是否过载或资源耗尽 | 进程、策略、连接数、硬件和日志 |
| 控制面与路由 | 控制连接、BGP 邻居、路由数量、路由变化、控制器可达性 | 是否存在路由收敛或控制面异常 | 邻居状态、路由策略、认证和控制连接 |
| 应用体验 | DNS 查询、TCP/SSL 握手、首字节时间、应用响应、MOS 或 QoE | 用户真正感受到的业务是否变慢 | 应用服务器、DNS、TLS、路径和终端接入 |
厂商文档通常把隧道健康与 QoE、平均延迟、平均丢包和平均抖动放在同一视图中；部分平台还按站点、对端和上行链路拆分统计。可参考 Cisco Catalyst SD-WAN 隧道健康监控说明 与 Cisco Meraki AutoVPN 隧道监控说明。
第一层：链路质量指标看什么
1. 延迟、RTT 与抖动
延迟通常表示探针或数据包从一个端点到另一个端点所需的时间；RTT是往返时间，更适合用于判断两端通信的整体等待成本；抖动则关注连续报文时延的变化。视频会议、语音和交互式远程桌面通常比批量传输更容易受到抖动影响。
监控时不要只存一个平均值。至少同时保留平均值、最小值、最大值和时间序列。Meraki 的监控页面会按所选时间范围展示延迟、抖动、丢包和 MOS 的平均、最小、最大值，这种记录方式有助于区分持续异常和短时尖峰。相关字段与查看方式见 官方监控步骤。
2. 丢包率
丢包率表示探测或传输报文未能按预期到达的比例。它可能来自运营商拥塞、无线接入、接口错误、设备队列丢弃或隧道路径问题。单独看到丢包时，先确认采集点：接口级丢包、隧道级丢包和应用实际重传并不一定相同。
3. 带宽利用率、吞吐量与接口错误
带宽利用率用于判断链路是否接近容量上限；吞吐量反映实际收发速率；接口 CRC、丢弃、重传或物理错误则用于发现端口、光模块、网线或协商问题。建议同时展示当前值、峰值、95 分位趋势和按小时或工作日的容量曲线，避免只在“已经变慢”后才发现链路长期接近上限。
一个可执行的面板字段组合是：接口在线状态、收发字节速率、利用率、错误包、丢弃包、时延、丢包、抖动和采集时间。若接口错误持续增加，即使隧道仍显示 UP，也应优先检查物理接口和上联设备。
第二层：隧道、站点和路径切换
隧道监控至少要区分隧道状态和隧道质量。UP 只说明控制或数据通道处于建立状态，不代表应用体验一定正常。建议记录隧道对端、使用的本地和远端上行链路、当前路径、平均时延、丢包、抖动、QoE、最近一次切换时间和近一段时间的切换次数。
Cisco Catalyst SD-WAN 的隧道表包含隧道状态、QoE、平均延迟、平均丢包、平均抖动及本地和远端 IP；其文档还给出了该产品自身的 QoE 健康分级。这个分级只能作为该平台的参考口径，不应直接当作所有 SD-WAN 产品的统一标准。详情见 Cisco 隧道健康指标说明。
路径切换次数是容易被忽略的指标。一次切换可能是正常的故障转移，连续切换则可能说明探针阈值过于敏感、两条链路质量接近、底层线路抖动或策略存在来回震荡。排查时把切换时间与丢包、抖动、接口状态和应用告警放在同一时间轴上。
部分平台通过持续性能探针测量每条隧道，并按对端和上行链路分别展示数据。Meraki 文档明确说明，隧道统计基于持续发送的性能探针，且不同对端或不同上行链路的观测值可能不同。不要把一个站点到一个对端的结果直接推广到全网。
第三层：设备资源与控制面
当多个站点同时出现高延迟、丢包或吞吐下降时，不能只盯着运营商线路，还要检查边缘设备是否过载。建议采集以下指标：
- CPU：当前值、峰值、持续时间，以及高占用时对应的进程或功能。
- 内存：使用率、可用量、回收或异常增长趋势。
- 会话与连接：并发会话、NAT 表、隧道数和策略命中量。
- 接口资源：收发速率、错误包、丢弃包、队列和端口状态。
- 控制面：控制连接、BGP 邻居、路由数量、路由变化和最近一次收敛时间。
- 设备健康：温度、电源、风扇、证书或密钥有效期，以及系统日志事件。
设备资源指标不能脱离业务负载解释。例如 CPU 短时升高可能来自配置提交、日志处理或流量突增；只有当资源异常与隧道质量、接口丢弃或应用响应同时变化时，才更适合将设备过载列为主要嫌疑。网络管理平台通常还会把设备状态、资源告警和日志统一呈现，H3C 的 SD-WAN 运维监控文档可作为这类平台设计的参考资料：H3C SD-WAN 运维监控部署指导。
第四层：应用体验指标不能缺席
只监控 Ping、RTT 和丢包，无法证明 SaaS、网页、语音或视频业务正常。应用层建议按实际业务选择合成探测或真实用户体验数据，重点观察：
- DNS 查询时间：判断名称解析是否成为首个等待环节。
- TCP 握手时间：判断建立连接前的网络和服务端响应。
- SSL/TLS 握手时间：判断加密协商、证书链或服务端响应是否变慢。
- 首字节时间：观察请求发出后，应用开始返回内容所需的时间。
- 末字节时间或完整响应时间：观察整个业务请求是否完成。
- MOS、QoE 或业务专用评分：用于语音、视频等对实时性敏感的业务，但必须注明计算方法和采集点。
Fortinet 的 SD-WAN 架构文档将性能探针用于测量延迟、抖动和丢包，并在应用监控中列出 TCP 握手、SSL 握手、首字节、末字节和 DNS 查询等指标。它们适合用于区分“网络路径正常但应用响应慢”的场景，具体能力仍取决于部署的平台和探针位置。参考 Fortinet SD-WAN/SD-Branch 7.6 架构文档。
最短实施流程：从零搭建 SD-WAN 监控面板
- 先定义监控对象。按站点、设备、WAN 接口、隧道、对端、应用和时间范围建立维度。没有这些维度，发现异常后很难定位到具体链路。
- 先采集基础必看指标。加入接口状态、收发速率、利用率、错误包、延迟、丢包、抖动、隧道状态、CPU、内存和控制连接。先确认每个指标的采集点、单位和时间戳。
- 补充路径与应用指标。记录当前选路、路径切换、DNS、TCP/SSL 握手和应用响应时间。对关键业务分别设置探测目标，不要只用一个公共目标代表所有应用。
- 建立基线。至少按工作时段、非工作时段、站点和链路类型分别观察正常范围。平均值用于总体趋势，最大值用于发现尖峰，分位数或时间序列用于识别持续拥塞。
- 设置连续异常告警。告警条件应包含指标、对象、持续时间和恢复条件。例如“某站点某隧道的丢包连续超过本组织基线一段时间”，比单次超过阈值更适合减少噪声。具体数值应根据线路类型、业务和历史基线设置，不能照搬单一厂商参考值。
- 定义验证和回退。告警触发后，先比较同一时间的接口、隧道、设备和应用数据；确认是链路问题后再执行切换、限流或策略调整，并保留原策略、配置变更记录和恢复步骤。
如果平台支持按平均、最小、最大值和时间点查看统计，优先使用原生时间序列而非只看当前状态。Cisco Meraki 的官方步骤明确建议按上行链路配对和时间范围查看这些指标，并通过图表时间点核对异常发生时刻。
用指标组合判断故障范围
| 现象组合 | 更可能的范围 | 下一步验证 |
|---|---|---|
| 接口错误增加，隧道丢包同步升高 | 物理接口、光模块、网线或上联设备 | 查看端口错误、协商状态、替换链路或对端端口交叉验证 |
| 接口正常，单条隧道时延和丢包升高 | 特定路径、对端上行或隧道探针 | 比较同站点其他隧道、其他上行和同一对端的多条路径 |
| 隧道 UP，但 DNS 或 TCP 握手变慢 | 解析服务、应用入口、策略或服务器响应 | 分别测试 DNS、TCP、TLS，并与其他站点探测结果比较 |
| CPU/内存高，多个隧道和应用同时变慢 | 边缘设备资源、策略或会话规模 | 查看进程、会话、队列、日志和最近配置变更 |
| 路径切换频繁，链路指标在阈值附近反复变化 | 探针阈值、链路抖动或策略震荡 | 对照切换时间、抖动曲线、探针目标和恢复条件 |
| 网络指标正常，首字节或完整响应时间升高 | 应用服务器、数据库、DNS 或服务端处理 | 从多个站点进行应用层探测，核对服务端日志和依赖组件 |
排障时优先选择能缩小范围的对比：同一站点不同链路、同一链路不同对端、同一应用不同站点，以及网络层与应用层的同时观测。不要仅凭单个平均值判断根因。
告警阈值怎么设计才不容易误报
- 分层：把链路、隧道、设备和应用分开设定，不要用一个阈值覆盖全网。
- 持续时间：短时尖峰可记录为事件，连续异常再升级为告警。
- 对象范围：明确是单接口、单隧道、单站点、站点组还是全局异常。
- 趋势结合瞬时值：利用率持续上升与单次峰值的处置方式不同。
- 告警关联：接口 DOWN 后，不要为其下游所有隧道和应用重复产生同等级告警。
- 恢复条件：告警必须定义恢复窗口，并保留触发、确认、恢复三个时间点。
- 平台差异：QoE、MOS、健康分级和性能探针的计算方式可能不同，面板上要显示采集来源和计算口径。
可以先用历史数据建立每条链路和每类业务的正常范围，再逐步加入业务重要性、工作时段和站点等级。对于语音、视频、跨地域办公等场景，应用体验指标通常比单纯的带宽利用率更能反映用户是否真正受影响。
常见问题
SD-WAN 监控最少要看哪些指标？
最低配置建议包含接口状态、延迟、丢包、抖动、带宽利用率、隧道状态、路径切换、设备 CPU/内存和一项应用响应指标。若只能先做一块面板，优先覆盖链路、隧道和应用三层，避免只看设备在线状态。
延迟、抖动和丢包哪个更重要？
没有脱离业务的统一优先级。批量传输更关注吞吐和持续丢包，语音和视频更容易受抖动、丢包和应用响应影响，交互式业务则通常同时关注 RTT 与首字节时间。应按业务类型建立基线，并在同一时间轴比较多个指标。
隧道显示 UP，为什么用户仍然觉得网络慢？
隧道 UP 只代表通道处于建立状态，不等于链路质量和应用服务正常。继续检查隧道时延、丢包、抖动、路径切换，以及 DNS、TCP/SSL 握手和应用响应时间。
要不要把 MOS 或 QoE 作为统一标准？
不建议直接统一套用。MOS、QoE 的计算方式、采集点和分级规则可能由平台实现决定。应记录平台版本、计算口径和探测对象，并把它与原始的延迟、丢包、抖动和应用指标一起查看。
监控告警应该按平均值还是最大值触发？
两者都不宜单独使用。平均值适合观察趋势，最大值适合发现尖峰，但持续异常更应结合时间窗口、分位数或连续采样次数。告警条件还应包含对象、持续时间和恢复条件。
常见问题
SD-WAN 监控最少要看哪些指标？
最低配置建议包含接口状态、延迟、丢包、抖动、带宽利用率、隧道状态、路径切换、CPU/内存和至少一项应用响应指标。
隧道显示 UP，为什么用户仍然觉得网络慢？
隧道 UP 不代表链路质量和应用服务正常，还要检查隧道质量、路径切换、DNS、TCP/SSL 握手和应用响应时间。
延迟、抖动和丢包哪个更重要？
取决于业务。语音和视频更关注抖动、丢包与应用响应，交互式业务关注 RTT，批量传输则更关注吞吐和持续丢包。
告警应该按平均值还是最大值触发？
不要单独使用平均值或最大值，建议结合时间窗口、连续采样、历史基线和恢复条件设计告警。