服务健康检测需三层验证：systemctl查真实状态、curl测接口可用性、ss/pgrep交叉定位；脚本须带日志、告警、容错与超时保护。
服务健康检测不能只看“进程在不在”，得从运行状态、端口响应、业务逻辑三层验证，否则容易误判假死或漏报异常。
用 systemd 统一查服务真实状态
别用 ps aux | grep，它匹配不准、易受干扰。systemd 的状态机才是权威依据：
- 用
systemctl is-active --quiet service-name判断是否处于 active 状态，返回 0 才算真正就绪 - 区分 failed、activating、deactivating 等中间态，避免把“正在启动”当成“已运行”
- 对非 systemd 管理的服务（如 nohup 启动的脚本），改用
pgrep -f "唯一标识"，比如启动时加-Dapp.name=api，再查pgrep -f "app.name=api"
用 curl 验证 HTTP 服务是否真能响应
端口通 ≠ 服务可用。Nginx 可能返回 502，API 可能返回 200 但数据为空。必须走真实请求路径：
- 命令示例：
timeout 5s curl -f -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8080/health -
-f让非 2xx/3xx 状态码直接返回非零退出码，方便脚本判断 -
-w '%{http_code}'输出实际状态码，可用于日志记录或二次过滤（比如只接受 200） - 务必加
timeout，防慢响应拖垮整个巡检流程
用 ss 和 pgrep 辅助交叉验证
当 systemctl 查不到、curl 又超时，需要进一步定位问题根源：
- 查端口监听：
ss -tln | grep ':8080'—— 比 netstat 更快更准，不卡 DNS、无缓存延迟 - 查进程存活：
pgrep -f "java.*myapp.jar"或更精准的pgrep -f "app.name=myapi" - 三者组合使用：先查状态 → 再试接口 → 最后查端口和进程，形成递进式排查链
写成脚本要带日志、告警和容错
自动检查不是跑一次就完事，得留下痕迹、触发提醒、扛住异常：
- 每次结果写入独立日志：
echo "$(date): nginx → $(systemctl is-active nginx 2>/dev/null)" >> /var/log/monitor.log - 异常时发系统日志：
logger -t monitor "nginx down!"，或邮件通知 - 脚本开头加
set -e（出错即停）、set -u（变量未定义报错），防止静默失败 - 所有外部命令套
timeout 10s，包括systemctl、curl、ss，避免卡死
