Docker 容器健康检查器

要解决什么问题

在容器化部署中，服务异常往往表现为 OOM killed、restart loop 或网络超时。这些症状在控制台输出中容易被淹没，开发者需要手动翻看 docker logs、执行 docker inspect、分析 docker stats，再结合 docker network inspect 来定位根因。当容器数量增长、或服务处于抖动状态时，这类排查工作既耗时又容易遗漏关键线索。

如何工作

该技能直接调用 Docker Engine API 的两个核心端点：

• /containers/{id}/json — 获取容器的元数据与状态信息
• /containers/{id}/stats — 拉取实时资源使用数据

在此基础上，它通过 /containers/{id}/logs 端点流式读取容器日志，进行自动化分析，定位三类典型问题：

1. OOM 杀死 — 识别 Exited 状态容器的退出码与 OOMKilled 标记
2. 重启循环 — 对比 RestartCount 与启动时间戳，判断是否陷入 crash-restart 模式
3. 网络连通性 — 结合 NetworkSettings 与端口映射信息，排查 Connection refused 或 No route to host 类问题

整个诊断流程不依赖外部工具链，仅通过 Docker Engine API 完成，适合集成进 CI/CD 流水线或运维脚本。

适用边界与注意点

• 需要宿主机具备 Docker Engine API 访问权限（通常为 docker.sock 或远程 API endpoint）。
• 仅适用于 Linux 容器环境，不涉及 Windows 容器或 Kubernetes 场景。
• 日志分析基于文本模式匹配，无法替代 APM 工具的深度性能剖析。
• 对于多容器编排场景，需逐个指定容器 ID 进行诊断，不支持服务级别的自动发现。