如何通过Docker的Healthcheck实现复杂业务探针，自动排除故障探针？

本文共计778个文字，预计阅读时间需要4分钟。

在Docker中使用HEALTHCHECK实现业务级探针，关键不在于复杂，而在于让检查命令真实反映业务可用性——例如数据库连接、缓存读写、下游依赖响应正常。单纯的端口号或进程存活检查远远不够，容易误报容器活着，服务已死的健康状态。

设计业务级健康检查命令

健康检查的核心是 CMD 后面那条命令，它必须能执行多步验证并统一返回退出码。推荐用 shell 脚本封装逻辑，避免单条 curl 或 telnet 的片面性。

• 把检查逻辑写进 ./health.sh 并 COPY 到镜像中，例如：
• 检查 HTTP 健康端点是否返回 200；
• 用 mysql -h db -u user -ppass -e "SELECT 1" 验证数据库可查询；
• 用 redis-cli -h redis PING 确认缓存服务响应；
• 任意一步失败就 exit 1，全部通过才 exit 0。

然后在 Dockerfile 中引用：

HEALTHCHECK --interval=20s --timeout=5s --start-period=60s --retries=3 \
CMD ["./health.sh"]

合理设置 start-period 和 timeout

业务服务启动慢很常见：Spring Boot 应用可能要 40 秒才完成初始化，依赖的 Redis 或 MySQL 也可能延迟就绪。如果没设好 --start-period，健康检查会在应用还没准备好时就开始失败，直接导致容器被反复标记为 unhealthy。

• --start-period=60s：给足 1 分钟宽限期，期间所有失败不计数；
• --timeout=5s：单次检查不能拖太久，否则会阻塞下一轮探测；
• --interval=20s：比默认 30s 更频繁一点，加快故障发现速度，但别低于 10s，避免压垮服务。

与编排系统联动剔除故障

Docker 自身只管标记 unhealthy，真正实现“自动剔除”要靠上层调度器：

• 在 docker-compose.yml 中，配合 depends_on.condition: service_healthy，确保上游服务等下游健康后再启动；
• 在 Kubernetes 中，把 Docker 的 HEALTHCHECK 映射为 readinessProbe，让 Service 自动从 endpoints 中移除 unhealthy 实例；
• Swarm 模式下，任务状态变为 unhealthy 会触发自动重启或重新调度到其他节点。

查看和调试真实健康状态

别只看 docker ps 里模糊的 “Unhealthy”，要用 inspect 深挖细节：

• docker inspect --format='{{.State.Health.Status}}' myapp —— 查当前状态
• docker inspect --format='{{json .State.Health.Log}}' myapp | jq —— 查最近几次检查的命令输出、退出码、时间戳，精准定位哪一步失败
• 如果日志里显示 exit code 1 且输出含 "redis timeout"，说明是缓存问题，不是应用本身崩溃。