一、轮询的死结

纯 SNMP 是拉模型：管理器问，设备才答。没人问的时候，设备一个字都不说。 所以「某个端口在 30 秒里丢了 500 个包」这种事，只能等下一轮轮询才被发现， 而那时的现场早就没了。 想早发现，就只能缩短间隔。 但每一轮都要把 N 个 OID 从头问一遍，问一次约 60 字节请求、答一次约 120 字节， 200 个 OID 就是 36000 字节一轮。 算下来 5 分钟一轮、一天 288 轮，就是一千多万字节。 改成 1 分钟一轮，流量翻五倍，而发现延迟只从 300 秒降到 60 秒。 这是一条很差的性价比曲线——因为绝大多数轮询都是「什么也没发生」。

二、十个组，核心是两个

RMON 全称是远程监控 MIB，它在 MIB 树上的位置是 1.3.6.1.2.1.16，是标准 MIB 的一个分支， 不是另一个协议。报文还是 SNMP 报文，只是查的东西换成了 RMON 自己。 RMON 一共定义了十个组，常用的六个是：

alarm 和 event 是这套设计的枢纽：一个负责判断，一个负责动作。 这两个拆开是有道理的——同一条阈值可以挂不同的动作， 今天发 Trap、明天写日志，改动作不用改判断。 还有一个容易被忽略的好处：设备自己会算差值。 轮询取回的是累计计数器，管理器要拿两次采样自己减； RMON 的 statistics 组直接在设备里算出「每秒多少字节」。 省下的不只是流量，还有管理器的计算量。

三、代价，以及今天的现实

「把判断下放」不是免费的，账单有四张：

第四张账单最容易出事：设备重启后时钟从零开始，告警时间戳就乱了， 事后拿两条日志对不上时间，排查就断在这里。 所以真实环境里必须配 NTP——「让所有设备的时间对齐」是所有监控系统的前提，不是可选项。 说句 2026 年的实话：RMON 已经很少人用了。 主流换成了两条路：一是 SNMP Trap 加自定义阈值，二是设备把指标直接推给采集器， 比如 sFlow、IPFIX、NetFlow。 但思路一点没变：把「采集」和「判断」分开，让正常的时候零流量、异常的时候秒级到达。 这正是二十多年前 RMON 想明白的那件事。

四、动手 Demo：RMON 想解决的是「轮询太慢」

算一笔账：200 个 OID、一问一答 180 字节，看轮询间隔缩短五倍时流量和延迟各变多少。

n = 200                       # 每轮查 200 个 OID
per_poll = (60 + 120) * n     # 一问一答约 180 字节

for interval in (300, 60):
    polls = 86400 // interval
    print(interval, "秒一轮 →", polls, "轮每天，",
          format(polls * per_poll, ","), "字节每天")

实跑输出：

--------------------------------------------------------------------
RMON 想解决的是「轮询太慢」
--------------------------------------------------------------------
**纯 SNMP 是「管理器去问，设备才答」**：**没人问的时候，设备什么也不说。**
**所以「一个端口在 30 秒里丢了 500 个包」这种事件，要等下一轮轮询才被发现。**

  做法                频率                 流量                             发现延迟
  ------------------------------------------------------------------------------------------------
  轮询间隔 5 分钟     288 次每天           10,368,000 字节每天              **最长 300 秒才发现**
  轮询间隔 1 分钟     1440 次每天          51,840,000 字节每天              **最长 60 秒才发现**
  RMON 告警           **事件发生就报**     **只报异常，正常时几乎为零**     **秒级**

**前两行说明「想快就得多花流量」**：
**间隔缩短 5 倍，流量就涨 5 倍，但延迟只从 300 秒降到 60 秒。**
**这是一条很差的性价比曲线。**
**因为绝大多数轮询都是「什么也没发生」。**

**RMON 的思路是「把判断下放到设备上」**：**你在设备里设一条阈值，超过就主动发一个告警。**
**管理器只在收到告警时才去查详情。**
**这样「正常」的时候零流量，「异常」的时候秒级到达。**

**代价是「设备要干活」**：

  代价             具体是什么
  -----------------------------------------------------------------------
  **设备 CPU**     **要持续采样、算差值、比阈值**
  **设备内存**     **要存历史样本（RMON 有 10 个组，其中好几个是表格）**
  **配置分散**     **阈值写在几百台设备上，改一次要跑一遍**
  **时间基准**     **设备时钟不准，告警时间就对不上**

**第四行是最容易出事的一条**：**设备重启后时钟归零，告警时间戳就乱了。**
**所以真实环境里必须配 NTP**——**「让所有设备的时间对齐」这件事，是所有监控系统的前提。**

**顺带说一句今天的现实**：**RMON 这套东西在 2026 年已经很少人用了。**
**主流换成了两种做法。**
**一是 SNMP Trap 加自定义阈值**，**二是设备直接把指标推给采集器**，比如 sFlow、IPFIX。
**思路还是同一个：把「判断」和「采集」分开。**

两行的比值就是答案：间隔缩短五倍，流量也涨五倍，延迟只从 300 秒降到 60 秒。 「十万级字节」听着不多，乘上设备台数就不一样了： 50 台设备按 1 分钟轮询，一天是 26 亿字节，约 2.6 GB。 而且这些流量 99% 在说「一切正常」。 所以 RMON 的真正卖点不是「省流量」， 而是「把无效流量砍到零」——正常时一个字节不发，异常时立刻发。

30 秒实验

1. 算一下：50 台设备、1 分钟轮询，一天总共多少字节？（51840000 乘 50，约 2.6 GB）
2. 想一下：RMON 的 alarm 和 SNMP Trap 是什么关系？（alarm 判断，event 决定发不发 Trap）
3. 想一下：为什么设备时钟不准会让告警彻底失效？

常见误区

1. 以为「RMON 是另一个协议」。 它是 MIB 的一个分支，报文还是 SNMP，只是查的对象变了。
2. 以为「RMON 让监控变轻」。 它把负载从网络搬到了设备 CPU， 低端交换机开了 RMON 会明显变慢。
3. 以为「阈值设得越细越好」。 每次采样都要算，组开得越多，设备越吃力。

下一节用三个真实用法收束 SNMP 这一块，顺带说清 32 位计数器为什么会绕圈。

• ☐ （本节完，下一节 8.6.4 SNMP应用举例）

相关笔记

• SNMP
• MIB
• SNMP应用举例
• 📚 图解TCP／IP · 索引