脚本化的意义
把健康检查写成脚本，目的是把判定标准从人的经验固化为可重复执行的逻辑。合格脚本有三个特征：退出码语义明确、输出可机读、失败原因可区分。设计上常见四类模式：存活探测、语义探测、阈值判定、依赖连通性探测，复杂度与开销逐级上升，应按层组合使用。
基本信息
| 退出码约定 | 0 健康、1 不健康，其他值视为脚本执行异常 |
|---|---|
| 输出约定 | 短结论加关键数值，便于日志检索与阈值比对 |
| 超时控制 | 脚本自身必须设超时，防止挂起被误判为健康 |
| 幂等要求 | 只读探测，重复执行不产生副作用 |
| 依赖最小化 | 只使用目标机上稳定存在的基础命令 |
典型使用场景
- 存活探测：只判断进程与端口是否存在，用于最外层快速判定
- 语义探测：请求业务接口并校验返回内容，覆盖依赖与配置错误
- 阈值判定：读取磁盘、内存、连接数等指标并按水位分级
- 依赖连通性：探测数据库、缓存、消息队列的连通与响应时间
- 编排集成：把脚本接入调度或编排平台的探针机制，用退出码驱动动作
四类探测模式对照
| 模式 | 判定依据 | 代价与局限 |
|---|---|---|
| 存活探测 | 进程或端口存在 | 开销极低但误判率高 |
| 语义探测 | 接口返回内容正确 | 能覆盖依赖，成本中等 |
| 阈值判定 | 指标超过设定水位 | 开销可控，需维护阈值 |
| 连通性探测 | 依赖可连且响应及时 | 能提前暴露依赖故障 |
检查脚本的骨架约定
检查脚本的骨架约定
# 统一约定：0 健康、1 不健康、其他为执行异常
set -u # 未定义变量即刻失败，避免静默误判
TMO=${TMO:-5} # 超时可外部注入，便于按环境调整
# 探测动作必须带超时，防止挂死被当作健康
timeout $TMO curl -fsS -o /dev/null -w %{http_code} http://127.0.0.1:8080/healthz || exit 1
# 结论行保持短且字段稳定，便于检索与比对
df -hP / | awk 'NR==2 {print disk_used_pct=$5}'
# 退出码表达明确结论，让调用方无需解析文本
exit 0退出码语义要统一：0 健康、1 不健康，其他值视为脚本自身异常。三者混在一起时，脚本缺陷会被当成服务故障触发处置，或者相反，真实故障被当成采集错误被忽略。
检查脚本不得包含写操作。清理临时文件、重启服务、扩容这类动作看似无害，但在高频调用下会变成新的故障源；确需修复应交由独立的处置流程承担。