在真实生产环境中，系统崩溃往往不是突然发生，而是长期资源异常累积的结果。CPU 飙高、内存耗尽、IO 阻塞、僵尸进程堆积，这些都可以在故障发生前被发现。
Shell 的价值，在于构建一套轻量级"健康巡检机制"。
一、什么是健康巡检
健康巡检不是监控系统（如 Zabbix 或 Prometheus），而是一种：
低成本
快速部署
无需额外组件
可直接运行在目标服务器
的巡检机制。
它通常通过 crontab 定时执行脚本，对关键系统指标进行采样，并在异常时记录或报警。
二、巡检指标如何选型
巡检脚本不能"什么都查"，否则既浪费资源，也无法聚焦问题。
一般分为四类指标：
-
CPU
-
内存
-
磁盘
-
进程
这四类指标覆盖了绝大多数系统稳定性问题。
三、CPU 维度巡检
CPU 关注两个问题：
-
总体使用率是否异常
-
是否存在单个进程占用异常
常用数据来源包括：
top
uptime
/proc/stat
巡检逻辑不是简单打印 CPU 使用率，而是：
-
判断是否超过阈值（例如 80%）
-
持续超过一定时间才报警
-
记录 TOP 进程
这三步缺一不可。否则短暂波动会产生大量误报。
运维思维是：过滤噪声，只关注持续异常。
四、内存维度巡检
内存问题通常比 CPU 更隐蔽。
关注指标：
-
可用内存
-
Swap 使用率
-
是否存在持续增长趋势（疑似内存泄漏）
在 Linux 系统中，可以通过 free 或 /proc/meminfo 获取数据。
关键点不在于"怎么查"，而在于"什么时候认为异常"。
例如：
-
内存使用率 > 85%
-
同时 Swap 使用率 > 20%
单指标异常未必有问题，但组合异常往往意味着风险。
五、磁盘维度巡检
磁盘问题是线上事故高发点。
关注两个核心指标：
-
使用率
-
inode 使用率
很多人只检查磁盘空间，却忽略 inode 耗尽导致无法写入文件。
df -h
df -i
是最基础的数据来源。
巡检策略：
-
使用率 > 80% 记录 warning
-
90% 触发报警
此外，还应关注日志目录增长异常，尤其是 Web 服务（如 Nginx）和数据库（如 MySQL）所在目录。
六、进程维度巡检
进程巡检是最容易被忽视但极其重要的一环。
关注点：
-
关键服务是否存在
-
是否有僵尸进程
-
是否有异常高占用进程
例如：
检查某核心业务进程是否在运行。
如果不存在，则立即重启或报警。
这类逻辑通常写成：
-
判断进程存在
-
不存在则执行重启命令
-
记录日志
这是一种基础的自愈机制。
七、巡检脚本的结构设计
一个成熟的巡检脚本应具备以下结构：
-
全局配置区（阈值定义）
-
各模块检查函数
-
统一日志输出函数
-
告警模块
-
主控制流程
不要把所有逻辑堆在一个文件里。
良好的结构可以支持：
新增检查模块
修改阈值
统一输出格式
这体现的是工程思维，而不是"命令集合"。
八、日志与报告机制
巡检脚本应将结果输出为结构化日志，例如：
时间戳
主机名
指标名称
当前值
状态（OK/WARNING/CRITICAL）
后续可以结合 logrotate 或集中收集机制。
如果规模扩大，可以逐步过渡到：
ELK（Elasticsearch + Logstash + Kibana）
但在初期阶段，Shell 足以胜任。
九、自动化与自愈的边界
必须明确一点：
自动重启服务 ≠ 高可用设计。
巡检脚本只能作为辅助保障，而不是架构替代。
真正的高可用体系应结合：
负载均衡
多节点部署
服务注册与健康检查
Shell 巡检是基础保障层，而非架构层解决方案。