企业官网建设流程全解析

—— 系列第二篇：十几台机器怎么盯？抖动过滤、三路告警、AI 预判，一套配全

本篇定位：上一篇讲了 AI SSH 运维 Agent 是什么、怎么上手。这一篇只解决一件事——人盯不过来的机器，交给它盯。从录入主机、写巡检规则，到抖动过滤、三路告警、事后回溯，全流程照抄即可。

目录

• 一、为什么传统监控总是"响得不对"
• 二、值守前的准备工作（照抄）
• 三、巡检规则怎么写（四个模板）
• 四、抖动过滤：让告警"响得准"
• 五、三路告警配置（界面 / WebHook / 邮件）
• 六、AI 预判：告警消息里直接带诊断
• 七、出了告警怎么处置（标准动作）
• 八、一周值守实录与心得
• 九、常见问题

一、为什么传统监控总是"响得不对"

先说一个多数人都有过的经历：告警邮件一天几十封，真正要命的没几封。仔细拆开看，问题出在三个地方：

1. 阈值太糙：CPU > 80% 就告警？编译机日常 90%，告警早就被你划成"狼来了"；
2. 没有抖动过滤：网络抖一下、进程重启一次，告警立刻就响了，两分钟后自己又好了，留下一条你永远不会看的记录；
3. 告警不带上下文：通知里只有"web02 CPU 高"，没有"为什么高、影响什么、该看哪条日志"。排查成本全留给了半夜被叫醒的你。

AI SSH 运维 Agent 的值守模块就是冲着这三点设计的：巡检脚本理解业务（而不是只看阈值）、连续 N 次异常才告警、告警消息附带 AI 初步诊断。

二、值守前的准备工作（照抄）

值守的前提是主机台账完整。建议按这个清单一次录全：

录完先手动跑一遍连通性检查：

检查一下所有主机的连通性，不通的列出来

经验：先手工巡检一轮再开值守。这一轮能暴露密钥没分发、防火墙没放行、账号权限不足这类低级问题，别让它们在半夜的告警里才冒出来。

三、巡检规则怎么写（四个模板）

值守的核心是"巡检剧本"。以下四个模板覆盖 90% 的日常场景，直接照抄改主机名即可。

模板 1：通用存活巡检（每 5 分钟）

每 5 分钟检查：web01 web02 web03 三台机器， SSH 可达、sshd 进程在、22 端口在听。 连续 3 次异常才告警。

模板 2：业务进程 + 端口巡检（每 10 分钟）

每 10 分钟检查 mgc01 上的 mysql 进程和 3306 端口， gluster-client 上的 glusterd 进程和 24007 端口。 异常时顺带 tail 最近 30 行对应服务日志。

模板 3：磁盘水位巡检（每 1 小时）

每 1 小时检查所有主机的磁盘使用率， 超过 80% 预警、超过 90% 告警， 列出占用最大的前 5 个目录。

模板 4：证书 / 大任务巡检（每天一次）

每天早上 9 点：检查各 nginx 的 SSL 证书剩余有效期， 少于 15 天的告警；顺便看一眼昨晚的定时任务执行记录。

写规则的口诀：查什么（对象）+ 多久查一次（频率）+ 什么算异常（判定）+ 异常了多吵（升级策略）。四要素写全，AI 不会歧义。

四、抖动过滤：让告警"响得准"

这是值守模块的灵魂。三个参数建议这么配：

一句话记住：告警的价值不在"响"，而在"响得准"。宁可晚响两分钟，也不要一天误报二十次把你的信任耗光。

五、三路告警配置（界面 / WebHook / 邮件）

三路通道按"紧急程度"分工：

1. 界面告警记录：所有事件都记，事后可回溯、可导出。这层永远开着；
2. WebHook 推送：对接钉钉 / 企微 / 飞书群机器人，值班群秒收。配置样例：

WebHook 地址：https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的key 触发条件：连续异常 ≥ 3 次的事件 消息模板：默认即可（已含主机、事件、AI 诊断三段）

3. 邮件通知：只留给最要命的事件（如数据库进程消失、磁盘 > 90%），避免邮箱被淹。

分工原则：界面全记、群聊收重点、邮件收命案。三层的阈值拉开，才不会一起变成噪音。

六、AI 预判：告警消息里直接带诊断

传统告警推送长这样：

[WARN] mgc01 mysqld 进程不存在

开了 AI 预判之后，推送长这样：

[WARN] mgc01 mysqld 进程消失 AI 诊断：最近一次变更：无（近 7 天）； 系统日志 03:47:12 出现 oom-killer 记录，victim=mysqld； 内存 7.4G/8G，InnoDB buffer pool 配置 6G 偏大； 建议：先确认数据无损坏后 systemctl start mysqld， 并将 innodb_buffer_pool_size 降至 4G 观察。

这就是"多模态 + 命令理解"带来的差别：告警不再只是触发器，而是一次半成品排障。你睡眼惺忪看完推送，已经知道该不该爬起来、起来先敲什么。

七、出了告警怎么处置（标准动作）

收到告警后的标准三步：

第一步：看 AI 诊断，判断等级。抖动恢复类直接忽略；真异常看"建议动作"。

第二步：让 AI 执行恢复（带确认）。

在 mgc01 上重启 mysqld，重启前先确认数据目录无只读， 重启后做一次端口和连接数检查

高危操作它会停下来等你点头，你确认的每一笔都有留痕。

第三步：事后复盘。在图形版的告警记录里按主机筛选当周事件，让 AI 汇总：

把本周所有告警按主机汇总，统计每台的告警次数和主要原因

复盘产出直接就是下周的巡检规则——这是值守体系自我改进的闭环。

八、一周值守实录与心得

拿真实数据说话（15 台混合主机，一周值守）：

三条心得：

1. 规则宁少勿滥：先只盯"挂了就出事"的东西（进程、端口、磁盘），两周后再逐步加；
2. 只读模式是最好的新手保护：第一周全组只读，大家敢用，才谈得上用好；
3. 把 AI 诊断当第二意见：它给的根因大多数时候靠谱，但恢复动作永远自己过一遍脑子。

九、常见问题

Q：AI 执行的命令会超出我授权的范围吗？
不会。只有台账内主机可连，高危命令二次确认，操作全留痕。给权限的正确方式是最小授权 + 流程兜底。

Q：值守期间断网 / 重启了怎么办？
恢复后自动补跑一轮全量巡检，中断期间的事件在界面里标为"断档"，不会静默丢失。

Q：误报还是多，怎么调？
先调"连续异常次数"（3→5），再看判定条件是否该加"业务视角"（如"nginx 5xx 率 > 5% 才算异常"，而不是"nginx 进程在"）。

Q：能盯 Windows 机器吗？
能。Windows 启用 OpenSSH Server 后照常接入，服务状态、事件日志、端口检查都支持。

本文为「AI SSH 运维 Agent」系列第 2/8 篇。下一篇：《Ollama 内网离线部署指南》——数据不出门的玩法。