ENGINEERING PLAYBOOK

Docker 日志排查路径与命令示例

Docker 日志排查要从可复现现象开始，而不是先更换工具或复制零散答案。本指南把问题拆成环境、输入、观察、假设、实验和结论六类证据，帮助开发者在不扩大变量的情况下定位原因。每一步都要求记录命令、版本、时间和预期结果，并优先对照正式文档；本站导航只承担发现入口，不把外部页面的旧结论直接当作当前系统事实。排查记录还应标明谁执行、在哪个环境执行、哪些变量保持不变以及如何回滚。若Docker 日志排查只在生产规模出现，应先用采样、只读指标和受控流量缩小范围，不能为了观察而关闭权限、清空日志或直接修改全部实例。最终结论需要同时解释成功样本与失败样本。

适用人群：负责容器应用开发、部署和运行故障定位的工程人员

诊断路径

  1. 现象冻结：写清Docker 日志排查发生的环境、版本、输入、时间和可重复步骤，区分稳定复现与偶发现象。
  2. 证据采集：保存状态码、日志、计时、配置差异和最小样本，先确认观察工具本身没有改变问题。
  3. 假设排序：按最近变更、依赖边界和影响范围建立候选原因，每次实验只改变一个变量。
  4. 闭环验证：修复后运行回归、反向测试和干净环境复现，记录适用版本与仍未覆盖的边界。

命令示例与执行步骤

  1. 建立最小复现，删除与Docker 日志排查无关的服务、插件和数据，同时保留能够稳定触发问题的输入。
  2. 记录客户端、运行时、依赖、操作系统和网络路径；使用版本化命令输出替代“应该一样”的口头判断。
  3. 从入口到下游逐层检查输入输出，在每个边界只采集必要证据，并对敏感字段脱敏。
  4. 为前三个假设分别写出支持证据、反证和最小实验，按成本与概率排序，不并行修改多处配置。
  5. 实施最小修复并补回归测试；再恢复真实规模，观察性能、错误率和资源变化，确认没有把故障转移到别处。

可复现任务记录

具体错误或任务

容器突然退出且应用日志不完整，需要同时检查退出码、OOM 标志和宿主机事件。

失败信号：容器状态 Exited，退出码为 137 或 OOMKilled=true，但应用日志没有完整异常栈。

最小输入

容器名、失败时间窗、镜像摘要、退出码、健康检查和宿主机资源事件。

验证命令或步骤

docker inspect --format '{{.State.ExitCode}} {{.State.OOMKilled}} {{.State.Error}}' app

预期输出

正常退出样本为 0 false；异常样本能给出非零退出码或明确状态字段。

失败输出

137 true 指向内存终止；125/126/127 分别需要检查启动、权限或命令路径。

成功判据

根因能够解释退出码与时间窗，修复后同负载运行且健康检查、日志和资源指标同时正常。

本任务常见错误

  • 只看 docker logs 忽略 State
  • 重启容器覆盖失败现场
  • 把日志缺失直接判断为应用无错误

资料与适用边界

状态字段和日志命令依据 Docker CLI 官方文档；具体退出码还需结合镜像入口和宿主机事件解释。

证据块复核日期：2026-09-04

可复现命令与代码示例

限定时间并带时间戳读取单个容器日志

docker logs --timestamps --since 15m --tail 200 CONTAINER

核对容器日志驱动与日志文件配置

docker inspect --format '{{.HostConfig.LogConfig.Type}} {{json .HostConfig.LogConfig.Config}}' CONTAINER

相关站内页面

资料依据与复核边界

技术事实优先依据所列正式文档，并要求在目标版本与可控环境中复现；站内导航仅用于补充工具和学习入口。

资料复核日期：2026-08-29