为什么需要一个看门狗
很多个人开发者或小团队把服务跑在云主机上，白天还好，半夜进程悄悄挂了、端口被占、磁盘写满，第二天才发现——用户早已流失。雇人值守不现实，买商业监控又是一笔开销。其实用系统自带的定时任务 + 几段探活脚本，就能做到零成本 7×24 守护，挂了自动拉起来，并在企业微信收到告警。下面把我们的实战做法拆开讲。
三层探活：别只 ping 端口
单层检查很容易误判。我们用了三层，任意一层失败才判定异常：
- TCP 层：探测关键端口（如 80/443/8088/8089）是否可连，确认进程在监听。
- HTTP 层：对业务页面发 HEAD/GET，要求返回 200，确认服务真的在干活而不是“端口假活”。
- 进程层：用任务列表确认目标进程名存在、非僵尸，防止“端口在但进程卡死”。
/api/health 才真正兜住。失败自动重启：先杀干净再拉起
判定失败后，脚本的逻辑是：先尝试优雅重启；若进程卡死无法退出，按进程名强制结束，再重新拉起。关键点有三个：
1. 重启前先记日志
每次探活写一行带时间戳的结果，失败时额外写一条告警日志。日志是事后定位的命根子，没有它你永远不知道是半夜几点挂的、挂了几次。
2. 重启要限频
别让脚本发现一次失败就无限重启，容易把机器打满。我们设了“同一服务 10 分钟内最多重启 N 次”的熔断，超过就升级为人工告警。
3. 用系统定时任务兜底
守护脚本本身也靠定时任务跑（我们每 30 分钟一轮），这样即使守护脚本自己崩了，下一轮定时任务还会把它叫醒——形成定时任务守护守护脚本的嵌套可靠性。
日志怎么查才不头大
- 固定目录按天滚动，文件名带日期，便于回溯。
- 探活结果与告警分两个文件，告警文件只放“需要人看”的内容。
- 定期用脚本统计“今日失败次数 / 最长连续在线时长”，做成周报。
告警推送到哪
探活发现异常且自动重启无效时，通过企业微信机器人把“服务名 + 时间 + 错误码”推到手机。注意：推送动作本身也要有失败兜底，别让“告警没发出去”导致你以为一切正常。
两个必须提醒的风险
单点风险
定时任务 + 脚本都跑在同一台机器上。如果这台机器整体宕机，看门狗也跟着死。预算允许时，至少把告警通道和一台备用探测机分开；纯免费阶段，至少保证告警能发出、且你每天早上有个汇总巡检。
备份优先于监控
监控能减少故障时间，但救不回被误删的数据。先做好数据库/配置定时备份，再谈自动化守护。我们的一条铁律：任何自动重启脚本，绝不在重启逻辑里顺手做“清理旧文件”这类危险操作。
可复制的最小清单
- 一份三层探活脚本（TCP + HTTP + 进程），纯系统命令或 Python 即可。
- 一个定时任务，每 10~30 分钟跑一次，失败记日志并尝试重启。
- 一个日志滚动 + 告警推送，告警失败要有二次兜底。
- 一份每日汇总，早上看一眼就知道昨晚稳不稳。
整套下来零云成本、零第三方依赖，一台最低配云主机就够。对小项目来说，这比花冤枉钱上重型监控实在得多——先把“半夜不爬起来”这件事解决掉，再谈精细化。