告警有两条路：设备推（Trap）与网管拉（轮询）。前者快可能丢，后者可靠但慢。 所以正确做法是两条都用——Trap 负责快，轮询负责不漏。
上一节讲 CPU 监控，这一节讲「出问题怎么让人知道」。 这一节的核心不是技术，是「告警设计」——大部分单位的告警是失效的。
一、两条路的取舍
方式 谁发起 实时性 可靠性
SNMP Trap 设备 秒级 UDP，可能丢 Syslog 设备 秒级 UDP，可能丢 SNMP 轮询 网管 取决于间隔 可靠，但发现晚
两条都用才是正解：Trap 丢了，下一次轮询还能发现；轮询发现得晚，Trap 已经先报过。 两者互补，不是二选一。
二、只靠轮询有多慢
最坏发现时间等于轮询间隔。 5 分钟轮询下，故障最坏要 5 分钟才发现。
对「端口 down」这种事件，5 分钟意味着业务已经投诉了。 而对「主备切换」这种事件，5 分钟意味着已经切换了五次。
所以「端口状态」与「设备可达性」这两类必须用 Trap， 而「流量趋势」「CPU 长期水平」用轮询更合适——它们不需要秒级精度。
三、告警设计三条原则
一、分级：致命（立刻打电话）、严重（半小时内）、一般（日报）。 全部标成「致命」等于没有分级——因为人会开始忽略所有告警。
二、去重与抑制：一台设备 48 个口同时 down，应该合并成一条「设备离线」，不是 48 条。 一次上联断可能产生几百条告警，邮件与短信瞬间被淹没，真正的根因那条反而看不到。
三、有恢复通知：只报「坏了」不报「好了」，运维会一直在猜到底恢复没有， 于是同一条告警被反复确认，效率全耗在这上面。
四、从「有告警」到「有用告警」
大部分单位的告警系统停在「有告警」这一步：能发邮件、能发短信，但没人看。
变成「有用」要加三样：告警要指向动作（这条告警该做什么，写在通知里）； 告警要有归属（谁负责，而不是发给一个公共邮箱）； 告警要有闭环（处理完要标记，否则无法统计误报率）。
一条检验标准：随机挑一条上周的告警，问「当时谁处理了、怎么处理的」。 答不上来，说明告警系统只是「在发消息」，不是在「管事」。
五、动手 Demo：告警靠 Trap 还是靠轮询，两者的取舍
这段对比 Trap、Syslog、轮询三种方式的实时性与可靠性， 再按四档轮询间隔算「只靠轮询」时的最坏与平均发现时间。
for iv in (30, 60, 300, 900):
P(u" 轮询间隔 %d 秒：最坏 %d 秒发现，平均 %d 秒。"
% (iv, iv, iv // 2))
实跑输出：
--------------------------------------------------------------------
告警靠 Trap 还是靠轮询，两者的取舍
--------------------------------------------------------------------
**告警有两条路**：设备主动推（Trap／Syslog），或者网管主动拉（轮询）。**两条路的可靠性完全不同。**
方式 谁发起 实时性 可靠性
-------------------------------------------------------------------
SNMP Trap 设备 秒级 UDP，可能丢
Syslog 设备 秒级 UDP，可能丢（可改 TCP）
SNMP 轮询 网管 取决于间隔 可靠，但发现晚
**所以正确做法是「两条都用」**：**Trap 负责「快」，轮询负责「不漏」。**Trap 丢了，
下一次轮询还能发现；轮询发现得晚，Trap 已经先报过。
**算一下「只靠轮询」的最坏发现时间**：
轮询间隔 30 秒：故障最坏要 30 秒才被发现（平均一半）。
轮询间隔 60 秒：故障最坏要 60 秒才被发现（平均一半）。
轮询间隔 300 秒：故障最坏要 300 秒才被发现（平均一半）。
轮询间隔 900 秒：故障最坏要 900 秒才被发现（平均一半）。
**5 分钟轮询下，最坏要 5 分钟才发现。**
**对「端口 down」这种事件，5 分钟意味着业务已经投诉了。**
**告警设计的三条原则**：
1. **分级**：致命（立刻打电话）、严重（半小时内）、一般（日报）。
**全部标成「致命」等于没有分级。**
2. **去重与抑制**：一台设备 48 个口同时 down，**应该合并成一条「设备离线」**，不是 48 条。
3. **有恢复通知**：只报「坏了」不报「好了」，**运维会一直在猜到底恢复没有。**
**第 2 条的现实意义**：一次上联断，可能产生几百条告警，
**邮件与短信瞬间被淹没，真正的根因那条反而看不到。**
「平均是一半」这个算法基于「故障在间隔内均匀发生」的假设， 真实情况常常更差——因为故障往往集中在业务高峰，而轮询不会因为高峰而加密。
「去重与抑制」是三条里最值钱的：它决定了告警系统「有没有用」。 一次上联抖动产生五百条短信，手机被打爆之后，人就会把短信通知全关掉——而关掉之后，下一次真正的故障就没人知道了。
最后那条「挑一条上周的告警问谁处理了」是检验标准，不是技术手段： 它把问题从「系统有没有建」变成「流程有没有跑」。这一句比前面所有技术细节都重要。
30 秒实验
- 看你的网管系统是靠 Trap 还是靠轮询。
- 查一下上个月的告警总数，看看有多少是重复的。
- 随机挑一条历史告警，问自己当时谁处理的。
常见误区
- 以为 Trap 可靠。UDP 会丢，网络一拥塞最先丢的就是它。
- 以为轮询够用。5 分钟间隔意味着业务先投诉。
- 以为告警越多越好。淹没之后等于没有告警。
自测三问（点开对答案）
1. Trap 与轮询各自的优缺点是什么？ —— Trap 秒级但可能丢；轮询可靠但发现晚，最坏等于一个轮询间隔。 2. 为什么告警要去重与抑制？ —— 一次故障可能产生几百条告警，淹没真正的根因，导致通知被整体忽略。 3. 什么是「有用的告警」？ —— 指向具体动作、有明确归属、能闭环统计，而不只是发出消息。下一节：告警要能对上时间——NTP。
- ☐ （本节完，下一节 03.07.05 设置时间）