Linux服务状态监控需组合进程、端口、功能三层检查，用轻量守护脚本补足systemd盲区，协同而非替代，并规避磁盘满、强杀、权限不足等常见陷阱。
Linux服务状态监控的核心是及时发现服务异常并自动恢复，关键在于用好系统自带工具、设置合理检查逻辑、避免误判和循环拉起。
快速检查服务健康状况
别只依赖systemctl is-active，它只反映 systemd 的单元状态，不等于进程真实可用。推荐组合验证：
- 进程层：用 pgrep -f "服务关键词" 或 ps aux | grep [s]ervice_name 确认主进程是否存在且非僵尸
- 端口层：用 ss -tlnp | grep :端口号 或 lsof -i :端口 检查监听是否正常（注意权限，普通用户可能看不到 PID）
- 功能层：对 Web 服务可 curl -sf http://127.0.0.1:端口/health | grep -q "ok"；数据库可用 mysql -h127.0.0.1 -uuser -ppass -e "SELECT 1" &>/dev/null
编写轻量可靠的守护脚本
脚本目标不是替代 systemd，而是补足其盲区（如进程僵死但 unit 仍显示 active）。重点控制三件事：检查频率、重启阈值、防抖机制。
- 用 sleep 控制轮询间隔，生产环境建议 10–30 秒，太短加重负载，太长影响恢复时效
- 单次失败不立即重启，先重试 2–3 次（每次间隔 2 秒），避免网络抖动导致误拉起
- 加入启动锁：用 flock -n /tmp/service-guard.lock -c "..." 防止脚本被重复执行
- 记录日志到 /var/log/service-guard.log，包含时间、检查结果、操作动作，方便追溯
与 systemd 协同而非对抗
守护脚本应作为 systemd 的补充，不是替代。推荐部署方式：
- 脚本本身用 systemd service 托管（Type=oneshot + Restart=always），由 systemd 保证脚本常驻
- 在服务 unit 文件中添加 ExecStartPost=/path/to/health-check.sh，实现启动后自检
- 禁用 systemd 自动重启（Restart=no），把恢复逻辑交给更灵活的守护脚本
避免常见陷阱
很多脚本上线后反而引发问题，多因忽略边界情况：
- 未判断磁盘满、内存耗尽等系统级异常，导致重启后秒退——检查前加 df / | awk 'NR==2 {print $5}' | sed 's/%//' | awk '$1 > 95'
- 用 kill -9 强杀，可能丢失数据或破坏状态——优先用 systemctl restart service_name 或服务自身 reload 命令
- 脚本运行用户权限不足，查不到进程或连不上端口——用 root 运行，或为对应用户配置必要 capability
- 未清理旧进程残留，重启后出现多实例冲突——拉起前先 pkill -f "旧进程关键词"，再 sleep 1 秒确保释放端口
