波仔
📡 第三章 路由器和它庞大的功能
📄 一句话概括

CPU 利用率有三个均值：5 秒看瞬时、1 分钟看刚才、5 分钟看长期。 三个都高时不要做重操作——敲一条 show 都可能引发路由震荡。

📝 本节和前面几节的关系

上一节讲日志，这一节讲「设备累不累」。 这是最常被问、也最容易被误读的一个指标。

一、三个均值各反映什么

均值 反映什么 什么时候看

5 秒 瞬时压力 现在有没有被顶住 1 分钟 短期趋势 刚才发生了什么 5 分钟 长期水平 这台设备忙不忙

为什么要三个：单个数值分不清「现在是尖峰」还是「一直这么忙」。 而这两种情况的处置完全不同——尖峰不用管，长期高要考虑扩容。

二、三种组合怎么读

5 秒高、5 分钟低 → 有瞬时突发。可能是正常的路由更新，也可能是攻击，也可能是刚开了 debug。 5 秒低、5 分钟高 → 持续负载。这是「设备快不够用了」的信号。 三个都高 → 已经过载，任何额外动作都可能引发故障。

第三种最危险：这时候敲一条「显示全部路由」都可能让 CPU 冲到 100%， 而协议报文一旦被丢，邻居就会断开，路由震荡。 一条排查命令引发一次全网故障，这种事真的会发生。

三、过载时该做什么

先降负载，再排查。

降负载的三个动作：带宽限速（把某个方向的流量压下来）、停掉不必要的日志与 debug、 暂停非关键的协议（比如把某个 BGP 邻居软关闭）。

然后才是排查：看进程占用、看接口流量、看有没有环路。 如果反过来「先排查」，很可能在排查的过程中把设备彻底压死。

四、监控本身也是负担

SNMP 轮询不是免费的：每次读 50 个 OID、每 10 秒一次，就是每秒 5 次读操作； 如果采集 500 个 OID、每 5 秒一次，就是每秒 100 次。

「每秒几百次读」对 CPU 是有感的。 所以网管软件「轮询越勤越好」是错的——监控本身的负担，可能比被监控的故障更严重。

折中办法：核心指标勤采、次要指标慢采、能用 SNMP Trap 推的就不用轮询拉。 这也是下一节讲告警时的原则。

五、动手 Demo：CPU 的三个均值，为什么不能只看一个

这段列出三个均值的用途，再按「一次轮询读多少 OID、多久一次」算三种采集策略下每秒的读操作次数。

for n, iv in ((50, 10), (200, 10), (500, 5)):
    P(u"  每次 %d 个 OID、每 %d 秒：每秒 %.0f 次读。" % (n, iv, n / iv))

实跑输出：

--------------------------------------------------------------------
CPU 的三个均值，为什么不能只看一个
--------------------------------------------------------------------
**路由器的 CPU 利用率有三个数**：5 秒、1 分钟、5 分钟。**它们不是重复，是三个不同的用途。**

  均值       反映什么     什么时候看
  --------------------------------------------------
  5 秒       瞬时压力     看「现在有没有被顶住」
  1 分钟     短期趋势     看「刚才发生了什么」
  5 分钟     长期水平     看「这台设备忙不忙」

**为什么三个都要看**：

  · **5 秒高、5 分钟低** → 有瞬时突发。**可能是正常的路由更新，也可能是攻击。**
  · **5 秒低、5 分钟高** → 持续负载。**这是「设备快不够用了」的信号。**
  · **三个都高** → 已经过载，**任何额外动作都可能引发故障。**

**「三个都高时不要做重操作」这一条很实用**：
这时候敲一条「显示全部路由」都可能让 CPU 冲到 100% 并丢协议报文，**引发邻居断开、路由震荡。**
**正确做法是先降负载（限速、停日志），再排查。**

**算一下 SNMP 轮询本身的负担**：

  每次读 50 个 OID、每 10 秒一次：每秒 5 次读操作。
  每次读 200 个 OID、每 10 秒一次：每秒 20 次读操作。
  每次读 500 个 OID、每 5 秒一次：每秒 100 次读操作。

**「每秒几百次读」对 CPU 是有感的。**
**所以网管软件「轮询越勤越好」是错的**——监控本身的负担可能比被监控的故障更严重。
**折中办法：核心指标勤采、次要指标慢采，或者用 SNMP Trap 代替轮询。**

「每秒 5 次」与「每秒 100 次」差 20 倍， 而它们采集的信息量可能只差 3 倍——因为「缩短间隔」比「增加指标」更伤设备。

「三个都高时不要做重操作」这一条要写成值班手册：它不是技术细节，是操作纪律。 新人最常见的事故就是「为了排查把设备查死了」。

最后「用 Trap 代替轮询」是本节与下一节的衔接：设备主动推的代价远低于网管主动拉， 而且实时性更好——代价是可能丢（UDP）。 所以正确做法是两条都用。

30 秒实验

  1. 在你设备上看一下三个 CPU 均值分别是多少。
  2. 看网管软件多久轮询一次、每次读多少指标。
  3. 想一想：如果 CPU 三个值都在 95%，你第一步会做什么？

常见误区

  1. 以为看 5 分钟均值就够了。它会掩盖瞬时尖峰。
  2. 以为 CPU 高就赶紧查。过载时先降负载，否则越查越死。
  3. 以为监控越勤越好。轮询本身会消耗被监控设备的 CPU。
自测三问（点开对答案） 1. 三个 CPU 均值分别反映什么？ —— 5 秒看瞬时压力，1 分钟看短期趋势，5 分钟看长期水平。 2. 三个值都高时应该先做什么？ —— 先降负载（限速、停日志、暂停非关键协议），再排查。 3. 为什么缩短轮询间隔比增加指标更伤设备？ —— 每次轮询都有固定开销，间隔减半等于开销翻倍。

下一节：设备出问题，怎么让人第一时间知道——告警。

相关笔记