彭大帅的AI运维助手——自然语言管理 Linux 集群与网络设备——第 3 篇 · 值守深夜谁值班：值守监测与三路告警

目  录

从「问它查」到「它主动盯着你」

轮询与阈值：一圈一圈地看

去抖：为什么不会刷屏轰炸

三路告警：横幅、报警音、邮件同时到

不止盯资源：角色感知探针

小结

从「问它查」到「它主动盯着你」

前两篇讲的是「你问、它跑」。但运维里最揪心的场景，往往是你根本没在问的时候：凌晨两点服务悄悄挂了，没人知道，直到早上用户反馈才被发现。

这台程序解决这个问题的答案，是一个常年驻留后台的值守监测器。打开「一键值守」开关，它就不睡觉了——按固定周期轮询所有主机的 CPU、内存、磁盘、关键服务，一旦异常，第一时间用横幅、报警音、邮件三路同时通知你，并附上对原因的初步定位。本篇拆开这套机制，讲清楚它怎么做到「该盯的都盯到，又不乱报警」。

轮询与阈值：一圈一圈地看

值守的核心是一个后台线程，默认每 30 秒轮询一轮所有主机的指标（interval: 30）。每轮里，每台主机的 CPU、内存、根分区磁盘（以及 swap）会被采集一次，与预设阈值比对。默认阈值是：

阈值可以按主机单独覆盖，比如给数据库机把连接数阈值调成 80%，给它配更高的 CPU 告警线。间隔和阈值都放在 config/monitor.yml，随时可调。

去抖：为什么不会刷屏轰炸

如果一超阈值就报一次，CPU 飘高那几秒就能刷几十条告警，谁也受不了。这里用了状态机去抖，核心原则是「只在状态变化时推一次」：

• 指标从正常 → 异常：推送一次 alert
• 指标从异常 → 正常：推送一次 recovered（已恢复）
• 持续异常期间：不重复推送

这样一条告警对应一段异常周期，事后再补一条恢复通知，形成闭环，既不刷屏，也不漏报。对部分误报敏感的探针（比如 kubectl、OpenStack CLI 偶发超时），还加了「连续 N 轮异常才告警」的防抖，进一步压掉假警报。

三路告警：横幅、报警音、邮件同时到

异常一旦确认，会通过三个通道同时通知，保证「无论如何都能看见」：

邮件通知是最后一道保险，也是最关键的一路——因为值守的意义就在于「人不在也能被发现」。它用纯标准库实现 SMTP 发送（零第三方依赖），走 daemon 线程消费一个告警队列，发送失败只记日志、不拖垮值守主流程。

为了避免告警风暴把邮箱塞爆，邮件还做了滑动窗口限流：60 秒窗口内最多发 5 封。SMTP 账号信息由你在界面手动填写，密码不留存在任何配置里。

不止盯资源：角色感知探针

只看 CPU 内存磁盘，还远远不够——数据库主从延迟、Web 访问 5xx 突增、K8s 节点异常、OpenStack 控制面告警，这些「业务级」的问题，通用指标根本看不出来。所以值守还内置了角色探针：

每台主机只挂它实际承担的角色（AI 会自主探测并写回配置），避免给一台机器挂满所有探针制造噪音。这些探针把值守从「看资源」提升到「看业务」，是整套监测真正值钱的地方。

小结

这一篇讲了「深夜谁值班」的答案：一个 30 秒一轮的后台监测器，靠阈值判定 + 状态机去抖 + 三路告警，把「异常发现」从「靠人盯」变成了「程序 24 小时盯着，出问题第一时间三路通知」。而角色探针更进一步，让它能看出业务级的故障。安全（第 2 篇）管的是「敢不敢让它跑」，值守管的是「出事能不能第一时间知道」——两者合起来，才让这台程序真正能「托付」。