健康检查应分三层：服务状态用 systemctl is-active（非 ps）、端口监听用 ss -tln（非 netstat）、响应内容用 curl -f -s -o /dev/null -w '%{http_code}'（设超时），所有命令必须加 timeout 防卡死。
服务进程是否存在，systemctl is-active 比 ps aux | grep 可靠
直接查进程容易误判：同名进程、僵尸进程、刚 fork 还没 exec 的子进程都会干扰结果。而 systemctl is-active 读取的是 systemd 的真实状态机，能区分 active、inactive、failed、activating 等精确状态。
实操建议：
- 用
systemctl is-active --quiet <service-name></service-name>配合$?判断，返回 0 才算真正运行中 - 避免用
systemctl status做健康检查——它输出冗长且可能因日志缓冲延迟返回旧状态 - 对非 systemd 服务（如用
supervisord或裸nohup启动的），必须换方案，systemctl is-active查不到
端口监听是否就绪，ss -tln 比 netstat 更快更准
netstat 在高负载机器上常卡住或返回过期缓存；ss 是内核态接口，响应快、无竞态，且默认不解析 DNS/服务名，避免超时阻塞。
实操建议：
- 检查某端口是否监听：用
ss -tln | grep ':8080'，注意-t（TCP）、-l（listening）、-n（数字端口）缺一不可 - 别只查
LISTEN状态——有些服务启动后先 bind 再 listen，中间有短暂空窗，需配合连接测试 - 容器环境里，
ss默认查 host 网络命名空间，进容器查得加nsenter或在容器内执行
服务响应是否正常，curl -f -s -o /dev/null -w '%{http_code}' 是最小可靠探测
仅通端口不等于服务可用：Nginx 可能返回 502，API 可能返回 200 但 JSON 结构错乱，数据库连接池可能耗尽。HTTP 状态码是第一道过滤器。
实操建议：
-
-f让 curl 在非 2xx/3xx 时返回非零退出码，方便脚本判断；-s关闭进度条；-o /dev/null丢弃响应体；-w '%{http_code}'输出状态码用于日志或二次判断 - 不要加
-I（HEAD 请求）——某些服务对 HEAD 返回 405，但 GET 正常，反而误报 - 超时必须设：
--connect-timeout 3 --max-time 5，否则慢响应会拖垮整个巡检周期
健康检查脚本里，timeout 命令不是可选项，是必选项
一个卡死的 curl、hang 住的 ss、或 systemd 卡在 deactivating 状态，会让整个检查脚本阻塞，进而导致监控告警失灵、自动恢复流程中断。
实操建议：
- 所有外部调用都套
timeout 10s，比如timeout 10s systemctl is-active nginx - 注意
timeout的信号行为：默认发SIGTERM，部分程序不响应，可加-s SIGKILL强制终止 - 别依赖
set -e自动退出——timeout超时后返回 124，但若后面跟了|| true就失效，每一行都要独立判断
真正难的不是写几个命令，而是把每个环节的失败路径都想全：服务存在但没监听、监听了但不响应、响应了但数据异常、检查命令自己先挂了。漏掉任意一环，健康检查就变成“假装在线”。
