—— 系列第二篇十几台机器怎么盯抖动过滤、三路告警、AI 预判一套配全本篇定位上一篇讲了 AI SSH 运维 Agent 是什么、怎么上手。这一篇只解决一件事——人盯不过来的机器交给它盯。从录入主机、写巡检规则到抖动过滤、三路告警、事后回溯全流程照抄即可。目录一、为什么传统监控总是响得不对二、值守前的准备工作照抄三、巡检规则怎么写四个模板四、抖动过滤让告警响得准五、三路告警配置界面 / WebHook / 邮件六、AI 预判告警消息里直接带诊断七、出了告警怎么处置标准动作八、一周值守实录与心得九、常见问题一、为什么传统监控总是响得不对先说一个多数人都有过的经历告警邮件一天几十封真正要命的没几封。仔细拆开看问题出在三个地方阈值太糙CPU 80% 就告警编译机日常 90%告警早就被你划成狼来了没有抖动过滤网络抖一下、进程重启一次告警立刻就响了两分钟后自己又好了留下一条你永远不会看的记录告警不带上下文通知里只有web02 CPU 高没有为什么高、影响什么、该看哪条日志。排查成本全留给了半夜被叫醒的你。AI SSH 运维 Agent 的值守模块就是冲着这三点设计的巡检脚本理解业务而不是只看阈值、连续 N 次异常才告警、告警消息附带 AI 初步诊断。二、值守前的准备工作照抄值守的前提是主机台账完整。建议按这个清单一次录全项说明主机名 / IP建议用业务别名如web01、mysql-master认证方式推荐 SSH 密钥密码也支持存本地分组按业务分web 组、db 组、大数据组模式生产库建议先设只读模式录完先手动跑一遍连通性检查检查一下所有主机的连通性不通的列出来经验先手工巡检一轮再开值守。这一轮能暴露密钥没分发、防火墙没放行、账号权限不足这类低级问题别让它们在半夜的告警里才冒出来。三、巡检规则怎么写四个模板值守的核心是巡检剧本。以下四个模板覆盖 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 不会歧义。四、抖动过滤让告警响得准这是值守模块的灵魂。三个参数建议这么配参数建议值说明连续异常次数3 次进程抖一下不响真挂了 15 分钟内必响恢复静默期10 分钟恢复后 10 分钟内反复横跳只记一条告警升级3 次 / 10 次超 3 次走 WebHook超 10 次追加邮件一句话记住告警的价值不在响而在响得准。宁可晚响两分钟也不要一天误报二十次把你的信任耗光。五、三路告警配置界面 / WebHook / 邮件三路通道按紧急程度分工界面告警记录所有事件都记事后可回溯、可导出。这层永远开着WebHook 推送对接钉钉 / 企微 / 飞书群机器人值班群秒收。配置样例WebHook 地址https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key你的key 触发条件连续异常 ≥ 3 次的事件 消息模板默认即可已含主机、事件、AI 诊断三段邮件通知只留给最要命的事件如数据库进程消失、磁盘 90%避免邮箱被淹。分工原则界面全记、群聊收重点、邮件收命案。三层的阈值拉开才不会一起变成噪音。六、AI 预判告警消息里直接带诊断传统告警推送长这样[WARN] mgc01 mysqld 进程不存在开了 AI 预判之后推送长这样[WARN] mgc01 mysqld 进程消失 AI 诊断最近一次变更无近 7 天 系统日志 03:47:12 出现 oom-killer 记录victimmysqld 内存 7.4G/8GInnoDB buffer pool 配置 6G 偏大 建议先确认数据无损坏后 systemctl start mysqld 并将 innodb_buffer_pool_size 降至 4G 观察。这就是多模态 命令理解带来的差别告警不再只是触发器而是一次半成品排障。你睡眼惺忪看完推送已经知道该不该爬起来、起来先敲什么。七、出了告警怎么处置标准动作收到告警后的标准三步第一步看 AI 诊断判断等级。抖动恢复类直接忽略真异常看建议动作。第二步让 AI 执行恢复带确认。在 mgc01 上重启 mysqld重启前先确认数据目录无只读 重启后做一次端口和连接数检查高危操作它会停下来等你点头你确认的每一笔都有留痕。第三步事后复盘。在图形版的告警记录里按主机筛选当周事件让 AI 汇总把本周所有告警按主机汇总统计每台的告警次数和主要原因复盘产出直接就是下周的巡检规则——这是值守体系自我改进的闭环。八、一周值守实录与心得拿真实数据说话15 台混合主机一周值守指标开值守前开值守后告警消息数 / 周20038其中需要人处理的说不清淹没在噪音里11平均确认耗时20 分钟登机排查3 分钟看推送即知夜间被叫醒次数42且都带诊断三条心得规则宁少勿滥先只盯挂了就出事的东西进程、端口、磁盘两周后再逐步加只读模式是最好的新手保护第一周全组只读大家敢用才谈得上用好把 AI 诊断当第二意见它给的根因大多数时候靠谱但恢复动作永远自己过一遍脑子。九、常见问题QAI 执行的命令会超出我授权的范围吗不会。只有台账内主机可连高危命令二次确认操作全留痕。给权限的正确方式是最小授权 流程兜底。Q值守期间断网 / 重启了怎么办恢复后自动补跑一轮全量巡检中断期间的事件在界面里标为断档不会静默丢失。Q误报还是多怎么调先调连续异常次数3→5再看判定条件是否该加业务视角如nginx 5xx 率 5% 才算异常而不是nginx 进程在。Q能盯 Windows 机器吗能。Windows 启用 OpenSSH Server 后照常接入服务状态、事件日志、端口检查都支持。本文为「AI SSH 运维 Agent」系列第 2/8 篇。下一篇《Ollama 内网离线部署指南》——数据不出门的玩法。