怎么通过健康检查快速识别并隔离故障容器节点-Docker-PHP中文网

健康检查核心在于主动预防而非被动响应，需按服务类型选对探针（http/tcp/exec/startup）、精准配置三大参数（initialdelayseconds、periodseconds、failurethreshold），并确保隔离机制生效与持续可观测。

健康检查不是“等出问题再处理”，而是让系统在故障刚露苗头时就自动识别、隔离，甚至尝试恢复。关键在于配置合理、路径精准、响应及时。

不同服务依赖的健康维度不同，不能统一用 HTTP：

Web 服务：优先用 HTTP GET 检查 /health 或 /ready，但注意区分用途——/health 只验证进程存活（不连 DB），/ready 才检查数据库、缓存等关键依赖；
数据库/消息队列：用 TCP Socket 更轻量，避免应用层接口未暴露导致误判；
启动慢的服务（如 Java 应用加载大模型）：必须配 startupProbe，否则 liveness 还没等它起来就反复重启；
有复杂业务逻辑的容器：写一个 shell 脚本做综合判断（比如检查 PID 文件 + 端口监听 + 关键临时文件存在），用 exec 方式执行。

参数设得太激进会频繁重启，太宽松又起不到隔离作用：

initialDelaySeconds：给足启动时间，比如 Spring Boot 默认需 20–40 秒，设成 45 更稳妥；
periodSeconds：高频探测利于快速发现，但别低于 5 秒（避免压垮健康端点），Web 类建议 10 秒，核心中间件可缩至 5 秒；
failureThreshold：设为 3 是常见起点，但若网络偶发抖动多，可调到 5，并配合 timeoutSeconds: 2 缩短单次等待，既防假死又避误判。

只把容器标为 unhealthy 不够，要让它“退出服务流”：

在 Kubernetes 中，readinessProbe 失败会自动从 Endpoints 移除，前提是 Service 的 selector 匹配该 Pod，且没有其他策略覆盖；
用 livenessProbe 触发重启时，确认容器内进程是可重复启动的（比如不要依赖外部挂载的锁文件）；
Docker Swarm 或独立 Docker 环境下，需配合外部负载均衡器（如 Nginx、Traefik）读取 docker inspect 的 .State.Health.Status 字段，动态更新后端列表；
建议加一条日志告警：当连续 2 次 unhealthy 出现时，触发钉钉/企微通知，并附上 docker logs --tail 20 快照。

配置完不等于跑通，得动手验证：

手动停掉应用的健康接口（比如 kill -STOP 主进程），看是否在 failureThreshold × periodSeconds 内变成 unhealthy；
用 docker inspect --format='{{json .State.Health}}' myapp 查看完整状态，重点关注 FailingStreak 和最近几次 Log 中的错误输出；
在 Prometheus + Grafana 中接入 container_health_status 指标（Docker Engine 24.0+ 原生支持），画出健康率趋势图，比人工翻日志更早发现劣化苗头。

不复杂但容易忽略