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）独立验证，避免与容器生命周期耦合过紧
