健康检查与重启策略：让容器「挂了能自己回来」

容器里进程还在，但数据库连接断了，接口全 500——这种「假存活」负载均衡照样往里打流量。

健康检查的价值就是把「进程存在」升级为「服务可用」。

先说结论

检查依赖而不是检查进程；重启策略要设上限，避免无限重启打满日志。

• 健康检查要访问真实依赖（DB/缓存）
• interval/timeout/retries 要匹配业务启动时间
• restart: unless-stopped 配合 healthcheck
• 反向代理按健康状态摘流量

先把问题说清楚

Docker 的 HEALTHCHECK 只标记状态（healthy/unhealthy），不会自动重启；compose 里可以让依赖方等待 healthy。

真正的自动恢复需要配合编排（Swarm/K8s）或外部监控重启。

具体怎么做

按顺序执行，每步都验证完再进下一步：

• 写健康检查命令：curl 本地 /health 或检查依赖连通
• 设置合理的 interval 与 start_period，避免启动期误判
• compose 里用 condition: service_healthy 控制依赖
• 重启策略设 unless-stopped，并限制最大重启次数
• 监控 unhealthy 事件并告警

参数与成本对照

把关键数值摊开，方便判断该选哪条路：

几个容易踩的坑

下面这些是最常见的错误做法：

• 健康检查只 ping 进程：依赖挂了照样 healthy
• start_period 太短：启动中被判死
• restart always + 应用崩溃循环：日志爆炸
• 健康检查里访问外网：网络抖动导致误判

最后补两句

健康检查的目标是「让错误尽早暴露」，而不是让监控图好看。

工具是手段，理解机制才是能力。命令记不住没关系，知道「该看什么」就够了。