从自然语言提问到值守告警闭环一次可复现的实战记录· 9节点3控制3计算3Ceph VIP 高可用入口· 含四组端到端故障演练的完整时间线· 连巡检探针自身的缺陷也是演练抓出来的目 录第一章 场景谁来巡检一个9节点集群第二章 交接AI 怎么认识这套集群2.1 纳管与角色识别2.2 探针分层不是所有节点看一样的东西第三章 实录一次完整的对话式巡检3.1 巡检对话和普通聊天的区别第四章 故障演练四组真实时间线4.1 演练一控制面容器故障4.2 演练二VIP/HAProxy 宕4.3 演练三控制面服务注册缺失4.4 演练四Ceph 降级与一个真实缺陷第五章 两种巡检形态与最终形态5.1 问答式 vs 值守式5.2 一次真实教训告警延迟的真相5.3 实录结论第一章 场景谁来巡检一个9节点集群先交代被巡检对象一套 Rocky9 Kolla-Ansible 20.6.0Epoxy 版的生产级高可用 OpenStack 集群9 节点三组角色——3 台控制节点ostk-ctl1/2/310.10.10.81~83跑 keystone/nova/neutron/glance/cinder/horizon 等全量控制面服务3 台计算节点.91~93跑 nova_compute 与 libvirt3 台 Ceph 节点.101~103提供外部块存储后端控制面服务统一走 VIP 10.10.10.84keepalived haproxy。这种规模的日常巡检清单人工做一遍大约是9 台逐台登录控制面 12 个关键容器逐个看状态7 个服务注册是否齐全compute service 有没有 downVIP 探活Ceph 集群健康加 mon 仲裁加 OSD 全量在线。全部做完二十分钟起步且做十次错两次——人都会漏。这篇实录记录两件事怎么把这套集群交给 AI Agent一次性配置以及之后巡检实际发生了什么对话式巡检 值守自动巡检 四组真实故障演练。所有时间线均为真实记录非设计稿。第二章 交接AI 怎么认识这套集群2.1 纳管与角色识别把 9 台主机加入 Agent 的主机清单后第一件事不是巡检是让 AI 自己搞清楚每台机器是什么角色。用 scan_roles 工具发起探测commitfalse 先预览AI 登录每台机器查特征指纹docker 里有 keystone 容器判定为控制节点、有 nova_compute 判定为计算节点、有 cephadm 判定为 Ceph 节点。9 台全部命中零误报对照组的 yum 源服务器没有误命中。确认无误后 committrue 写回值守监测立即按角色挂上对应探针。2.2 探针分层不是所有节点看一样的东西巡检的核心设计是按角色分层——控制节点关心容器健康计算节点关心 nova_compute 活着Ceph 节点关心集群健康而不是单机负载角色节点巡检内容ctl3 台 .81-8312 个关键容器健康keystone/nova 三件套/neutron/glance/cinder/placement/horizon/haproxy/keepalived/mariadbctl1 额外做集群级7 服务注册、compute service、VIP 探活cmp3 台 .91-93nova_compute/nova_libvirt/neutron_openvswitch_agent 容器健康ceph3 台 .101-103cephadm 部署的 systemd 单元ceph1 额外跑 ceph -s 判定 health/mon 仲裁/OSD 在线数一个实现细节OpenStack CLI 认证不走 source admin-openrc.shkolla_toolbox 以非 root 用户运行读不了 0600 权限文件而是每次动态从 passwords.yml 读 admin 密码、以环境变量内联方式注入 docker exec。密码不落日志、不进配置文件。docker exec -e OS_USERNAMEadmin -e OS_PASSWORD动态读取 \-e OS_AUTH_URLhttp://10.10.10.84:5000 ... \kolla_toolbox openstack service list第三章 实录一次完整的对话式巡检配置完成后日常巡检就是一句话的事。以下是一次真实巡检的交互记录回显做了节选【向 AI 提问】「OpenStack 集群现在的状态怎么样全面查一下。」【AI 执行过程】它先 SSH 到 ctl1依次执行了这些命令每一步都实时可见 docker ps --format {{.Names}} {{.Status}} # 容器健康keystone Up 3 days (healthy)nova_api Up 3 days (healthy)...12个关键容器全部 healthy openstack service list # 经 kolla_toolbox控制面服务keystone / neutron / nova / glance / heat / heat-cfn / placement openstack compute service list3台compute全部 enabled 且 up curl -s -o /dev/null -w %{http_code} http://10.10.10.84:5000/v3/200 # VIP 探活正常 cephadm shell -- ceph -s # 登录 ceph1HEALTH_OK, 3 mon 仲裁正常, 24 OSD 全部 up【AI 结论】「集群整体健康控制面 12 容器全部 healthy7 项服务注册完整3 计算节点在线VIP 认证入口 200Ceph HEALTH_OK 无降级。无异常项。」整个过程不到两分钟。人工巡检容易漏的三类问题——compute service 显示 down 但进程还在、某个容器 unhealthy 但服务还能响应、Ceph 集群 HEALTH_WARN 但存储还能用——都在 AI 的检查路径里因为它执行的是清单不是感觉。3.1 巡检对话和普通聊天的区别值得强调的是安全边界这套巡检全程只有只读命令但 AI 毕竟持有可变更的权限。项目的分级管控在巡检场景下的表现是查询类命令直接放行假如巡检结论之后用户顺口说「那把 heat 服务重建一下」这类变更命令会触发人工确认而不是直接执行。巡检归巡检变更归变更边界不因对话连续而模糊。第四章 故障演练四组真实时间线巡检能力是不是真的演练是唯一标准。对集群做了四组端到端故障注入每组完整记录从注入到告警到恢复的全时间线。4.1 演练一控制面容器故障时间事件17:32:34注入docker pause keystonectl117:34:07[alert] 服务容器 keystone 异常Up 11 minutes (Paused)——约93秒17:34:36恢复docker unpause keystone17:35:25[recovered] 服务容器 keystone 已恢复——约49秒这次演练先失败了一次第一次用 docker stop 注入值守毫无反应。排查发现不是探针 bug——kolla 容器带 restart 策略被 dockerd 几秒内自动拉起探针采到的就是正常状态。教训是演练方法论的对容器化服务注入故障必须用 docker pausedockerd 不会自动恢复且探针的异常正则覆盖 Paused 状态stop 只能骗到自己。这条经验同样适用于 K8s/Harbor 等一切带 restart 策略的容器演练。4.2 演练二VIP/HAProxy 宕同时 pause 全部 3 台控制节点的 haproxyVIP 10.10.10.84 断连。113 秒后告警「VIP/HAProxy 探活失败HTTP 000」恢复后约 48 秒收到探活正常。注意这里如果逐台 stopkeepalived 会让 VIP 漂移到存活节点探活根本不会断——要打断 VIP 必须三台同时处理这也是 HA 设计的验证点。4.3 演练三控制面服务注册缺失注入方式更刁钻openstack service delete 删掉 heat 的服务注册服务还在跑但 keystone 里不注册了。41 秒后告警「控制面服务缺失 1: heat」。这个演练还顺带验证了联动告警的正确性VIP 宕期间 CLI 连不上认证端会误报「7 个服务全缺失」VIP 恢复自动回正——告警系统对「自己探活不了」和「服务真没了」做出了正确区分。4.4 演练四Ceph 降级与一个真实缺陷注入停止 ceph3 的一块 OSDsystemctl stop ceph-fsidosd.2预期 Ceph 进入 HEALTH_WARN 并告警。结果不告警。排查发现这是一个真实的探针缺陷判定函数检查的异常键是 bad/down/missing而 Ceph 采集数据用的键是 ok/health——okFalse 时永远走不到异常分支「永不告警」。修复方式是新增布尔判定加去抖commit 920c53f补 3 项单测重启后重新演练46 秒告警「Ceph 集群不健康HEALTH_WARN(osd down)」恢复后约 150 秒收到 HEALTH_OK。这段的价值在于展示了演练的另一半意义演练不仅验证「告警能不能响」还会暴露「判定逻辑写错了但从来没被触发过」的暗病。没有这次演练这个永不告警的缺陷会一直安静地躺着。第五章 两种巡检形态与最终形态5.1 问答式 vs 值守式对话式巡检第三章适合变更前后、上班第一眼的主动检查值守式巡检第四章背后的机制则是后台常驻每 30 秒一轮全节点轮询异常经双去抖确认后告警恢复后自动闭环 recovered。两者的检查项完全一致只是触发方式不同。值守的告警链路是三路的Web 界面弹横幅带未恢复告警面板、三连急音、可选邮件。去抖参数取的是经验值连续 2 轮异常才告警滤掉偶发超时连续 3 轮正常才报恢复滤掉抖动。5.2 一次真实教训告警延迟的真相K8s 集群演练时曾遇到「故障 15 分钟不告警疑似线程卡死」的现象排查后真相完全不同主机清单里还有 9 台已下线的旧虚拟机值守每轮仍对它们做完整 SSH 存活探测每台超时十几秒把单轮巡检拖到 5~8 分钟告警自然就慢了。把离线主机移出清单后告警提速到 27 秒。教训监控系统的「慢」先查轮询路径的最坏情况不要先怀疑线程模型下线主机的处置移除或排除是值守的卫生学。5.3 实录结论这套「AI 角色探针 故障演练」的巡检体系交付验证时真机 21 项全过、单测 136 项全过四组演练全部 alert 到 recovered 闭环。对个人运维者来说它把「二十分钟起步且会漏」的人工巡检变成了「两分钟问答 后台 30 秒一轮自动值守」对企业来说它的价值更进一步巡检路径是代码化的、可回归的演练抓出的每一个暗病都会变成测试用例沉淀下来。最后给想复现的人一句建议先做第二章的角色识别与探针配置再做第三章的问答式巡检建立信任最后才上值守——顺序反了你会在没有信任基础的情况下被告警噪音淹没。