容器健康检查需定义合理、响应及时、恢复可控，须真实反映业务可用性而非仅进程或端口状态，配合超时重试、编排联动、熔断兜底与持续验证。

容器健康检查不是简单加个HEALTHCHECK指令就完事，关键在于定义合理、响应及时、恢复可控。健康状态必须真实反映服务可用性，而自动恢复不能替代根本问题排查。

健康检查指标要贴近真实业务可用性

避免只检查进程是否存在或端口是否监听——这些容易产生“假阳性”。例如一个Web服务可能进程在、端口通，但数据库连接已断、缓存雪崩、线程池耗尽，实际已无法处理请求。

• HTTP服务建议用curl -f http://localhost:8080/health，后端实现/health端点：主动探测依赖（DB、Redis、下游API），返回结构化JSON并带各组件状态
• 非HTTP服务（如消息队列消费者）可提供本地健康接口（如Unix socket或TCP探针），或通过exec脚本检查关键文件锁、消费延迟、积压队列长度等业务指标
• 超时时间设为依赖最慢环节的1.5倍（如DB平均响应200ms，则健康检查timeout建议设为300ms），避免误判；重试间隔需大于单次检查耗时，防止探测风暴

利用Docker原生机制触发可控重启

Docker自身不支持“自动修复”，但可通过健康状态联动容器生命周期管理。核心是让编排层或守护进程感知失败并决策。

• 在docker run中启用--health-start-period=30s（避开冷启动抖动）、--health-retries=3、--health-interval=10s，确保状态稳定后再纳入负载
• 使用docker-compose.yml时配置restart: on-failure或unless-stopped，配合healthcheck，使健康失败后自动重建容器（注意：数据卷和网络状态保留）
• 生产环境推荐用Swarm或Kubernetes——它们能基于健康状态执行滚动更新、隔离故障节点、甚至调用webhook通知运维介入

自动恢复必须设置熔断与人工兜底

无限制自动重启可能掩盖资源泄漏、配置错误或上游故障，导致“重启风暴”或雪崩扩散。

• 在健康检查脚本中加入失败计数器或时间窗口限流（如5分钟内最多重启3次），超过阈值则停止自愈，改写入日志并触发告警
• 容器启动时生成唯一ID并记录到日志，配合ELK或Loki做失败模式聚类分析——连续重启是否都卡在DB连接？是否总在内存增长到800MB后失败？
• 关键服务禁用restart: always，改用on-failure + 健康检查，并配置Prometheus+Alertmanager监控docker_container_health_status指标，异常时短信/电话升级

验证与持续优化健康策略

上线前必须模拟典型故障场景，确认健康检查能准确识别、恢复动作符合预期，且不影响上下游。

• 手动注入故障：用iptables封禁DB端口、kill -STOP主进程、填满磁盘至95%，观察健康状态变化时间和容器行为
• 用docker inspect <container> | jq '.State.Health'</container>实时查看状态细节，重点关注Status、FailingStreak、Log字段
• 将健康检查脚本版本化，与应用代码共仓管理；每次发布新镜像前，在CI阶段运行健康检查冒烟测试（如启动容器→等待健康→调用接口→验证返回）

健康检查不是开关，而是服务可观测性的入口；自动恢复不是免责条款，而是争取人工干预的时间窗口。真正可靠的系统，永远把“可诊断”放在“可自愈”之前。