与其等出事再翻日志，不如每天一分钟巡检：os-health.sh 快速体检 + 九大项巡检详细体检，两个脚本直接抄走

一、部署概述

上篇回顾：（五）单机故障排查实录——273 字节镜像坑的完整定位与修复，以及通用排查起手式。

本篇把前五篇的排障经验“反刍”成两个可长期复用的脚本。写脚本的动机很朴素：排查事故时最贵的成本是“想起来该查什么”，巡检脚本的价值就是把这个记忆固化成每天一分钟的例行确认。

二、脚本 1：环境健康检查（os-health.sh，快速体检）

一分钟内回答五个问题：服务在不在？计算服务正常吗？网络 agent 活着吗？资源还够吗？关键资源数量对吗？

bash

脚本里两个 ★ 都是实测踩出来的经验，不是抄来的：

1. unknown 不等于故障：nova-api / glance-api / keystone / placement-api由 httpd 承载（mod_wsgi），systemd 里根本没有这些单元名，is-active返回 unknown。脚本干脆把 active 和 unknown 都视为正常，避免巡检误报。
2. -f value多列输出会堆叠难辨：openstack hypervisor stats show这种多字段的输出，加一堆-c再用-f value会把所有值竖着堆在一起根本对不上号，直接看表格反而清晰。

三、脚本 2：九大项巡检（详细体检）

作用：输出系统基础信息、MariaDB、RabbitMQ、Keystone、Glance、Nova、Neutron、Cinder、Horizon九大项状态，所有输出同时打屏并落日志（tee -a），方便事后追溯巡检历史。

bash

设计要点：

• 每段独立，某一项报错不影响后面各项继续跑
• 2>&1把报错也收进日志——巡检日志的价值恰恰在于记录“当时报了什么”
• tee -a追加不覆盖，日志随时间累积成巡检历史，出事后可以翻“最后一次正常是什么时候”

四、巡检判读要点（每一项怎么看）

五、顺手收录：镜像相关操作速查

巡检之外，日常操作频率最高的是镜像管理，一并整理：

bash

五点五、九大项完整脚本（后四项补全）

第（三）节留了 [6]~[9] 的空白，这里补全，拼起来就是完整的九大项巡检：

bash

判读要点：

• [6]里 nova-compute 必须存在且 up，conductor/scheduler 也是；down立即去对应节点查日志
• [7]关注 Alive 列，False 表示 agent 与 MQ 断连
• [8]cinder-volume 由 cinder-volume 服务承载（不是 httpd）
• [9]302 是正常值（跳转登录页），200 反而少见；000/502 才是异常

把这四段接在第（三）节后面，脚本就闭环了——从系统到存储到 Web 入口，一屏看尽全部核心链路。

六、脚本进阶：给巡检加告警阈值

现在的脚本只“报状态”，进阶做法是让它“下判断”——对关键指标设阈值，超标就标红：

bash

exit 1这个细节很关键：脚本有了非零退出码，就能被 Zabbix/Prometheus 的探针直接拉去当采集脚本用。

七、巡检发现的典型问题与处置对照

八、把巡检纳入日常

我的实际用法供参考：

bash

• 手动巡检跑 os-health.sh（快速），出问题再跑九大项（详细）
• 巡检日志保留 90 天，事故复盘时“最后一次正常状态”全靠它
• 巡检脚本的真正价值不是“自动化”，而是把排障经验固化成每天一分钟的例行确认

下篇预告：（七）多节点部署：环境准备与应答文件——单机玩熟了，把 compute 角色拆到另外两台机器上，走向“迷你私有云”。三台机器的“步调一致”是新的挑战。