在容器化环境中，应用日志是定位故障、分析性能和追踪安全事件的重要依据。很多“容器日志突然消失”的问题，并不是应用没有输出，而是日志驱动选择不当、轮转策略未配置、容器被重建，或日志已经发送到外部平台。本文将从 Docker 日志驱动配置入手，给出一套可执行的排查方法，帮助运维人员快速找回日志线索。🔍
一、理解 Docker 日志的流转方式
Docker 默认收集容器主进程写入标准输出和标准错误的数据，也就是 STDOUT 与 STDERR。执行 docker logs 容器名 时，看到的通常就是这两条输出流经过日志驱动处理后的内容。如果应用只把日志写入容器内部文件，例如 /var/log/app.log，而没有同步输出到 STDOUT 或 STDERR，那么 docker logs 可能为空。
每个 Docker 守护进程都有默认日志驱动，容器创建时会继承该配置，也可以通过启动参数单独覆盖。Docker 默认使用 json-file，此外还支持 local、syslog、journald、fluentd、gelf、awslogs、splunk 等驱动。不同驱动在存储位置、日志轮转、远程传输和 docker logs 兼容性方面存在差异，具体列表可参考 Docker 日志驱动官方文档。
二、查看当前使用的日志驱动
首先执行 docker info，在输出中查找 Logging Driver，即可确认守护进程默认使用的驱动。检查某个容器时，可执行以下命令：
docker inspect -f '{{.HostConfig.LogConfig.Type}}' 容器名
如果需要同时查看容器的日志选项，可执行：
docker inspect -f '{{json .HostConfig.LogConfig}}' 容器名
这一步非常关键，因为修改 daemon.json 后，已有容器不会自动切换到新的日志配置。只有重新创建的容器才会应用新的默认驱动；单纯重启旧容器通常无法完成切换。
三、配置默认日志驱动与轮转策略
在 Linux 环境中，Docker 守护进程配置通常位于 /etc/docker/daemon.json。若希望继续使用 json-file，同时避免日志无限增长，可以配置如下内容：
{
“log-driver”: “json-file”,
“log-opts”: {
“max-size”: “20m”,
“max-file”: “5”
}
}
其中 max-size 表示单个日志文件达到指定大小后进行轮转，max-file 表示保留的文件数量。daemon.json 中的 log-opts 值必须写成字符串形式，即使参数看起来是数字，也应使用引号包裹。保存后可以先执行 dockerd --validate --config-file=/etc/docker/daemon.json 检查配置，再重启 Docker 服务。
对于不依赖直接读取 JSON 日志文件的普通场景，也可以使用 local 驱动。该驱动默认启用轮转，并采用更高效的存储格式，能够降低磁盘被日志占满的风险。配置方式如下：
{
“log-driver”: “local”
}
针对单个容器，可以在创建时指定参数，例如 docker run --log-driver local 镜像名。需要强调的是，不建议直接使用编辑器修改 Docker 管理的日志文件，否则可能造成文件状态异常或影响守护进程读取。
四、容器日志丢失的常见原因
- 容器被删除或重新创建：json-file 等本地日志通常与容器生命周期关联。执行 docker rm、重新部署 Compose 项目或更新服务后，旧容器日志可能随之移除。
- 日志发生轮转：配置 max-size 和 max-file 后，超出保留范围的历史日志会按策略删除，这属于预期行为，并不一定是故障。
- 应用未输出到标准流：应用把日志写入自身文件时，docker logs 无法直接显示。应调整应用配置，将日志输出到 STDOUT、STDERR，或挂载日志目录并配置采集器。
- 使用远程日志驱动：syslog、fluentd 等驱动可能把日志发送到外部服务。若禁用了双重日志缓存，docker logs 可能无法返回完整内容，应到对应日志平台查询。
- 磁盘空间或 inode 耗尽：宿主机磁盘满后，Docker 和应用都可能无法继续写日志。需要同时检查 df -h 与 df -i 的结果。⚠️
- 外部日志服务异常：网络中断、DNS 解析失败、证书过期、接收端限流或队列阻塞，都可能导致远程日志延迟或丢失。
五、推荐的日志丢失排查顺序
- 执行 docker ps -a，确认目标容器是否仍然存在，并记录容器 ID、创建时间和退出状态。
- 执行 docker inspect，检查日志驱动、日志选项、挂载目录及容器重启次数。
- 使用 docker logs --timestamps --since 1h 容器名，按时间范围读取日志，避免一次加载过多内容。
- 进入容器检查应用配置，确认日志究竟写入标准流还是内部文件，同时核对应用自身的轮转规则。
- 检查宿主机磁盘、inode、系统时间和 Docker 服务日志，例如通过 journalctl -u docker 查找写入失败或驱动报错。
- 如果采用远程驱动，继续检查接收端状态、网络连通性、认证信息、缓冲队列和日志平台的保留策略。
排查时应保留哪些证据
在重建或删除容器之前，建议保存 docker inspect 输出、容器 ID、镜像版本、启动参数、日志驱动配置以及故障时间段。若日志仍位于容器内部文件中，应先通过 docker cp 或挂载目录完成备份。不要在证据未保存时执行系统清理、强制轮转或删除容器，否则可能失去最后的排查线索。
六、生产环境配置建议
生产环境应优先让应用输出结构化日志到 STDOUT 和 STDERR，并为本地日志设置明确的大小与数量上限。重要业务日志应发送到集中式日志平台，结合时间同步、访问控制、传输加密、容量告警和保留周期管理。部署变更时还应记录旧容器与新容器的对应关系，避免因为容器名称相同而误判历史日志仍然存在。
对于远程日志链路，需要关注发送失败时的行为：应用或容器是否被阻塞、驱动是否支持缓冲、接收端不可用时如何告警。相关行为因日志驱动而异，配置前应查阅 Docker 容器日志说明，并在测试环境模拟网络中断和磁盘不足等场景。
总结
Docker 日志排查的核心是确认“日志写到了哪里、由谁保存、保留多久”。面对日志丢失，应依次检查容器生命周期、标准输出、日志驱动、轮转策略、磁盘状态和外部接收平台。合理选用 local 或配置了轮转的 json-file，并将关键日志集中存储，可以显著降低磁盘占满和历史记录无法追溯的风险。✅
