摘要

  • RFC 1224 用 maxAlertsPerTime、windowTime 和 alertsEnabled 限制单个代理产生的全部告警。
  • 触线后，代理发送一次 alertsDisabled 并停止异步上报，但这最后一条通知本身也可能丢失。
  • 独立的轮询日志用编号保存告警副本；读出或删除一行，仍不能证明有人处置了故障。

1991 年的难题不是“有没有告警”

RFC 1224 发布于 1991 年 5 月。RFC Editor 条目将其列为实验性文档，IETF Datatracker保留了 Alert-Man 工作组的文档身份。它没有规定什么条件应该触发告警，也没有规定告警内容；它研究的是告警生成之后，信息如何不压垮管理端、又不因传输失败而消失。

异步通知会向两个方向失真。机器或网络已经损坏时，不能指望它可靠报告自身故障；链路反复上下波动时，又可能把大量通知灌进已经吃紧的管理路径。前者让“没有消息”不可信，后者让“消息很多”反而损害管理能力。

当时的协议环境强化了这个矛盾。RFC 1157让 SNMP 建立在不可靠数据报服务上，Trap-PDU 的目的地址由实现决定。RFC 1215虽给出了 TRAP-TYPE 的定义惯例，却强烈反对不断增加新 trap。定义一种消息，不等于获得它送达的证据。

“销钉”把沉默变成一个状态

RFC 1224 的第一套办法叫滑动窗口“销钉”。maxAlertsPerTime 规定最大数量，windowTime 规定观察区间，而且计数覆盖代理产生的所有告警类型，而不是每类各有额度。

代理启动时，alertsEnabled 为真。每次本地生成告警，先检查这个开关；为假则不发送，为真才发送并记录时间。当固定数量的告警挤进窗口，代理发出一次 alertsDisabled，随后把开关置为假。

这一步保护 CPU、带宽和管理端容量，却创造了新的证据缺口：宣布“以后不再发”的最后一条通知也可能丢失。因此文档要求管理端在常规轮询中检查 alertsEnabled。如果发现它为假，管理端可以重新开启，同时必须承认静默期间可能已有 trap 丢失。

所以，安静不是健康的反证。它可能是限流算法正在工作。

日志保存的是保管链，不是处置结论

第二套办法是“轮询式已记录告警”。每个本地生成的告警都形成一行：递增的 alertId 与封装在 OPAQUE 中的 alertData。管理端可以查询下一条或指定编号，取得完整副本，并可选择通过 SNMP SET 或 CMOT 的相应操作删除。RFC 1189提供了文中 CMOT/CMIP 操作示例的时代背景。

这条保管路径独立于异步送达。网络隔离结束后，管理端仍可能回收隔离期间的历史。但表不是永久档案：容量满时，最老的一行会被新记录覆盖。优先返回最老记录只能降低风险，不能保证每件事都等到采集。

编号的证明力也有限。它说明代理按该机制生成并暂存过一条记录，却不能证明异步副本离开主机、网络送达、管理端在覆盖前读到、内容准确，或有人采取行动。

删除更不是“已解决”的同义词。删除只能证明某个管理视图发生了状态变化。在多管理端环境里，不同 community 可以拥有不同阈值、开关和日志视图；一个管理端重新开启或删除，不必改变另一个管理端所见。

一条告警其实是一串事件

可靠记录至少要分开保存：故障条件、告警规则、记录生成、开关读取、窗口判断、发送尝试、网络送达、管理端接收、日志入表、轮询返回、删除、人员研判、修复动作与服务结果。产品界面可以把它们压成一个图标，事实不会因此合并。

RFC 1224 还明确说没有讨论安全问题。因此 GET、SET、DELETE 的发生，不能反推出操作者身份或授权合法性。

来源