核心是让容器主动报告健康状态：Docker HEALTHCHECK 指令配合 --start-period 等参数实现主动探活，docker ps 和 inspect 可观察状态，结合 on-failure 重启策略形成自愈闭环，并通过 Prometheus 等监控异常趋势。
核心是让容器自己“说话”——不是等它挂了才报警，而是它主动报告“我卡住了”或“我好了”。Docker 原生的 HEALTHCHECK 指令就是干这事的，配合状态观察和自动响应策略，就能实现真正的主动监控。
在镜像里内置健康检查逻辑
这是最稳妥的做法，所有基于该镜像启动的容器默认带健康探活能力：
- 在 Dockerfile 中写明检查命令，比如：
HEALTHCHECK --interval=30s --timeout=5s --start-period=60s --retries=3 CMD curl -f http://localhost:8080/health || exit 1 - --start-period=60s 很关键：给慢启动服务（如 Java 应用、数据库）留足初始化时间，避免一上来就误判
- 命令必须返回 0 才算健康，非零即失败；确保容器内装了所需工具（如 curl、mysqladmin、pg_isready）
- 别只测端口通不通，要验证业务逻辑——比如访问
/health返回 200，或执行mysqladmin ping确认数据库可连可查
运行时动态验证与观察状态
容器跑起来后，立刻能确认健康机制是否生效：
- 用
docker ps看 STATUS 列：会显示(healthy)、(unhealthy)或(starting) - 用
docker inspect --format='{{json .State.Health}}' 容器名查详细状态，包括当前 Status、连续失败次数 FailingStreak 和最近几次检查的 Output - 如果看到
"Status": "unhealthy"，说明检查已触发且连续失败达到阈值，不是没运行，而是明确报错
结合重启策略形成自愈闭环
光知道不健康还不够，得让它自己动起来：
- 启动容器时加上
--restart=on-failure:3：当健康状态变成unhealthy或进程退出码非 0，最多自动重启 3 次 - 更进一步，用
docker-compose.yml配置：restart: on-failure+health_check块，编排层能感知健康变化并决定是否剔除或重建 - 注意区分：Docker 的
restart policy响应的是进程退出或健康失败；而 Swarm/K8s 会把unhealthy当作“不可用”，自动从负载均衡池中摘除
进阶：对接监控系统做趋势分析
单个容器状态是瞬时的，长期看异常模式才有价值：
- 用 cAdvisor + Prometheus 抓取
container_status{state="unhealthy"}指标，查某容器是否频繁进出 unhealthy 状态 - 写 PromQL 规则，比如：
count by (container_name) (changes(container_status[1h]) == 1) > 5，表示 1 小时内健康状态反复切换超 5 次，大概率存在不稳定问题 - 搭配 Alertmanager，在连续 unhealthy 超过 2 分钟时发告警，而不是等它彻底死掉才通知
