Docker容器Running状态仅表示主进程存活，不等于应用健康；需通过healthcheck、进程诊断、资源监控和自动化告警实现真实可用性保障。

当Docker容器显示为Running状态，不代表内部应用真正健康或进程持续可用——它只说明容器的主进程（PID 1）仍在运行。真正的监控需穿透容器外壳，观察实际业务进程是否存活、响应、资源可控。

识别“假Running”：常见失效场景

容器状态为Running，但业务已不可用，典型情况包括：

• 主进程卡死或陷入无限循环，未退出但不响应请求
• 应用启动失败后崩溃，但启动脚本未正确退出（如忽略 exit code），导致容器保留在Running状态
• 子进程异常终止，而主进程未监听或未做兜底处理（如未设置 restart policy 或 healthcheck）
• 内存耗尽触发OOM Killer杀掉关键子进程，但主进程仍存活

启用并验证容器健康检查（Healthcheck）

Docker原生healthcheck是判断容器真实可用性的最轻量方式。它定期执行命令，依据返回码和超时判定状态：

• 在 Dockerfile 中添加：HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 CMD curl -f http://localhost:8080/health || exit 1
• 构建后运行：docker run -d --name myapp myapp-image，再执行 docker inspect myapp | grep -A 5 Health 查看实时健康状态
• 注意：--start-period 给应用留出初始化时间；避免健康端点本身依赖复杂中间件（如DB未就绪时返回失败）

进入容器诊断实时进程与资源

当健康检查失败或怀疑异常时，快速进入容器排查：

• 查看进程树：docker exec -it ps auxf，确认主进程及关键子进程是否存在、CPU/内存占用是否合理
• 跟踪日志流：docker logs -f --tail 100 ，关注启动后是否有 ERROR、panic 或反复重连日志
• 检查资源瓶颈：docker exec -it top -b -n 1 | head -20，或使用 docker stats 查看宿主机视角的CPU、内存、网络IO
• 若进程僵死，可尝试发送信号：docker exec kill -USR2 1（假设应用支持热重载）或 kill -TERM 1 触发优雅退出

自动化监控与告警建议

单靠人工检查不可持续，推荐组合以下方式构建闭环：

• 在宿主机部署 cadvisor + Prometheus + Grafana，采集容器级指标（如 container_health_status、container_processes）
• 通过 docker events --filter 'event=die' --filter 'event=health_status:unhealthy' 实时捕获异常事件，配合脚本自动重启或通知
• 对关键服务，在应用层暴露 /metrics 或 /health 端点，并用外部探针（如 Prometheus Blackbox Exporter）独立验证，避免与容器生命周期耦合过紧