2. 需求分析：确定监控指标与用户角色

好，咱们进入实战的第二站。说实话，很多做监控看板的项目，一开始就栽在了需求分析上。我见过不少团队，上来就堆 Grafana 图表，什么指标都往上怼，结果老板看不懂，运维嫌太吵，最后沦为摆设。

为什么会这样？说白了，就是没想清楚两个问题：监控什么？给谁看？

今天咱们就把这两个问题掰开揉碎了讲。我个人习惯，做任何看板之前，先拿张白纸，把指标和角色画清楚。嗯，咱们现在就来干这个事。

2.1 核心监控指标：专线的四大金刚

专线质量好不好，不是靠感觉的。我这些年跟专线打交道，总结下来，核心指标就四个：延迟、抖动、丢包率、带宽利用率。你想想看，这四样东西，基本能覆盖一条专线 90% 以上的健康状态。

2.1.1 延迟（Latency）

延迟就是数据包从 A 点到 B 点跑一趟的时间。单位通常是毫秒（ms）。

• 为什么重要：延迟高了，用户访问体验直接崩。比如视频会议卡成 PPT，远程桌面操作像在泥潭里走路。
• 怎么测：最常用的就是 ICMP Ping。但我提醒你一句，有些网络设备会限制 ICMP 优先级，导致测出来的数据不准。我在项目中遇到过这种情况，后来改用 TCP Ping 或者 UDP 探测，才拿到真实数据。
• 阈值参考：

  等级	延迟范围	说明
  优秀	< 30ms	同城专线或优质链路
  良好	30ms - 80ms	国内跨省专线常见值
  一般	80ms - 150ms	跨境或长距离链路
  差	> 150ms	需要立即排查

2.1.2 抖动（Jitter）

抖动，说白了就是延迟的变化量。两个连续数据包，一个花了 10ms，一个花了 50ms，这中间的差值就是抖动。

• 为什么重要：抖动对实时业务是致命的。比如 VoIP 语音，延迟高一点还能忍，但抖动一大，声音就断断续续，根本没法听。
• 怎么测：连续发送多个 Ping 包，计算每个包延迟的标准差。一般建议连续发 100 个包以上，样本量太少没意义。
• 阈值参考：抖动 < 10ms 算优秀，10-20ms 可接受，超过 20ms 就要警惕了。

2.1.3 丢包率（Packet Loss）

丢包率就是发送的数据包中，有多少没到达目的地。单位是百分比。

• 为什么重要：丢包率哪怕只有 1%，对 TCP 传输的影响都是灾难性的。因为 TCP 有重传机制，丢一个包可能引发一连串的超时等待，吞吐量直接腰斩。
• 怎么测：同样用 Ping 或者专业的网络探针。注意要区分是单向丢包还是双向丢包。有些链路是单向故障，只丢一个方向的数据。
• 阈值参考：丢包率 < 0.1% 算正常，0.1%-0.5% 需要关注，超过 0.5% 必须立即处理。

2.1.4 带宽利用率（Bandwidth Utilization）

这个指标最直观，就是专线用了多少带宽。但很多人只看一个数字，其实不够。

• 为什么重要：带宽利用率接近 100% 时，延迟和丢包率会急剧恶化。这就像高速公路，车一多，大家都跑不动。
• 怎么测：通过 SNMP 协议从网络设备上采集接口流量。注意要区分入方向和出方向，很多专线是上下行不对称的。
• 阈值参考：

  等级	利用率范围	说明
  空闲	< 30%	带宽充裕
  正常	30% - 70%	日常运行范围
  高负载	70% - 90%	需要关注，考虑扩容
  拥塞	> 90%	立即扩容或限流

2.2 用户角色定义：谁在看这个看板？

指标定好了，接下来就是分角色。不同的人，关心的东西完全不一样。我见过最蠢的设计，就是给老板看一堆技术指标，给运维看一堆业务指标。嗯，咱们得避免这个坑。

2.2.1 网络运维工程师（一线）

这是看板的主要使用者。他们需要的是实时、精细、可操作的数据。

• 关注点：当前延迟多少？丢包率有没有突变？哪个端口带宽快满了？
• 需要的能力：快速定位问题、查看历史趋势、导出原始数据。
• 我的建议：给运维的看板，一定要有告警功能。比如延迟超过 100ms 就弹窗，丢包率超过 0.5% 就发邮件。别让他们一直盯着屏幕看。

2.2.2 网络架构师（二线）

架构师不关心每一秒的数据，他们看的是趋势和模式。

• 关注点：本周的延迟比上周高了 10%？带宽利用率是不是在持续增长？
• 需要的能力：周报/月报自动生成、容量规划预测、多链路对比分析。
• 避坑指南：我曾经给架构师做过一个看板，放了太多实时数据，结果他说「我看不懂」。后来改成以天为粒度的趋势图，他才满意。记住，不同角色，粒度不同。

2.2.3 业务部门负责人

业务方不关心技术细节，他们只想知道专线有没有影响业务。

• 关注点：今天视频会议卡不卡？文件传输慢不慢？
• 需要的能力：业务健康度评分、SLA 达标率、一句话总结（比如「专线状态良好」）。
• 我的经验：给业务方的看板，尽量用颜色。绿色代表正常，黄色代表预警，红色代表故障。别放折线图，他们看不懂。放一个大的仪表盘，指针指在「健康」区域，就够了。

2.2.4 管理层（CTO/CIO）

管理层要的是决策依据。他们不会天天看，但看的时候一定要能抓住重点。

• 关注点：专线整体可用率是多少？这个月花了多少钱？要不要扩容？
• 需要的能力：月度 SLA 报告、成本分析、扩容建议。
• 注意：给管理层的看板，数据要精炼。我一般只放三个数字：本月可用率、本月平均延迟、本月最大带宽利用率。再多，他们就烦了。

2.3 知识体系结构图

说了这么多，咱们用一张图把核心逻辑串起来。这张图我画了很多次，每次做新项目都会拿出来参考。

2.4 总结一下

需求分析这一步，说白了就是两件事：定指标、分角色。指标要精，四个核心指标足够覆盖 90% 的场景。角色要清，不同的人给不同的视图。

我个人习惯，在开始写代码之前，先跟每个角色的代表聊一聊。问他们三个问题：

1. 你每天/每周/每月看几次这个看板？
2. 你最想从看板上看到哪三个数字？
3. 如果看板只能告诉你一件事，你希望是什么？

这三个问题问完，需求基本就清晰了。嗯，咱们下一节就开始动手设计数据采集方案。