排查 Docker 容器问题时，logs、exec、inspect 我怎么组合着用

很多人第一次排查 Docker 容器问题，都会先看日志。这一步当然没错，但如果只停在日志层，很容易卡住。因为容器问题经常不是单点故障，它可能同时涉及启动参数、挂载路径、网络配置、环境变量以及容器内部运行状态。

所以我后来更喜欢把三条常用命令串成一个固定诊断流，而不是想到哪查到哪。

第一步先看 logs：确认症状

logs 最适合做的不是下结论，而是快速确认症状：

• 服务有没有报明显异常
• 是启动时报错，还是运行一段时间后出错
• 容器是不是反复重启

这一层能帮我先判断问题像不像应用级错误，但它通常还不够解释根因。

第二步再进 exec：确认容器里的真实状态

日志告诉你“发生了什么”，exec 更像是在看“容器内部现在到底是什么样”。
我通常会进去核对：

• 配置文件是否存在
• 挂载目录是不是预期内容
• 进程、端口、权限有没有异常

很多时候，应用日志里报的是“连不上”“找不到”“权限不足”，真正原因要进容器看才知道。

第三步用 inspect：确认容器外部定义

如果 logs 和 exec 看完还是对不上，我就会去看 inspect。
因为这一步给的是“容器被怎么定义出来”的信息，包括：

• 环境变量
• 端口映射
• 挂载卷
• 启动命令
• 网络配置

这层信息特别适合查那种“代码明明没问题，但容器行为就是不对”的场景。

为什么这三步组合起来更稳

因为它们对应的是三个不同视角：

• logs 看症状
• exec 看现场
• inspect 看定义

只看其中一个视角，很容易误判。
比如日志里报数据库连接失败，问题可能在应用配置，也可能在容器网络；进容器里看到文件缺失，根因又可能是外部挂载没配对。

小结

容器排障最怕的不是命令少，而是脑子里没有顺序。
我现在处理 Docker 问题时，基本都会先确认症状，再看现场，最后对照定义。把 logs、exec、inspect 组合起来，很多原本模糊的问题会快得多地收敛下来。