Docker容器退出后日志查找与持久化方案全解析

前几天凌晨一个同事发来一串消息服务挂了容器显示 Exited (137)我重启之后原来的容器已经被--rm自动删掉了现在docker logs直接报No such container日志去哪查这个“查看已退出docker容器的日志”的需求几乎是所有用 Docker 部署过服务的人都会撞上的问题。它其实包含两条完全不同的分支容器只是退出但没被删和容器对象已经被删掉。很多人一路折腾到第二个分支才发现自己当初根本没留后路。这篇把两个分支全部展开梳理docker logs什么时候有效、什么时候失效、容器删了还有没有抢救空间以及怎么从根上避免这种尴尬。1. 容器退出不等于容器消失先看清 Exited 与 Removed 的差别先解决一个最常见的误区很多人以为容器退出后日志就没了或者以为只要退出就还能查。实际上“退出”和“删除”是两个完全不同的阶段日志的可查性也完全不一样。1.1 Exited 状态下的容器docker logs 依然有效Docker 容器的生命周期大概是这样走的created→running→paused→exited→deleted。你要记住一个关键点exited只是进程结束了容器对象本身还留在 Docker 的存储目录里它的标准输出和标准错误信息也依然被记录在日志文件里。只要这个容器没有被docker rm掉docker logs就一直能用。我随便拿一个极端例子验证一下启动一个马上崩掉的容器docker run --name app-test alpine sh -c echo 启动中; sleep 2; echo 准备退出; exit 1命令结束后容器会停在Exited (1)状态这时候执行docker ps -a | grep app-test docker logs app-test输出完全是正常的启动中 准备退出这个例子看着简单但它揭示了docker logs的本质它读的不是容器进程而是 Docker 为容器保存的日志文件。进程退出、容器转为 Exited都不会影响这个文件的存在。1.2 Removed 后 docker logs 失效这才是真正的问题当你执行docker rm container_id或者容器启动时加了--rm参数容器退出后会被 Docker 自动清理掉这时候容器对象消失了同时与它关联的日志文件也会被清除。docker logs自然会报No such container。这里有个很常见的坑很多人用docker run --rm跑临时任务或测试容器以为“反正是临时的退出就清理很干净”。但生产环境里如果某个服务是手动用这种方式启动的一旦它因为崩溃退出容器会立刻被删掉连找日志的机会都没有。我自己就见过有同事在服务器上跑了一个 cron 任务容器加了--rm某次任务异常退出了排查时才发现日志早没了只能从上层调用方的输出里猜原因。所以拿到问题先别急着翻日志先回答一个前置问题容器只是Exited还是已经被Removed这决定了后面所有操作的方向。1.3 四种状态一个表格说清楚不同状态下docker logs的可查性我整理成了一张很直接的对照表容器状态容器对象是否存在默认日志文件是否存在docker logs 可用性running运行中是是可用exited已退出未删除是是可用removed已被 rm 删除否否默认情况下不可用--rm 自动删除否否默认情况下不可用可能有人会问如果容器被删了日志文件是不是一定没了不一定但那是特殊情况后面专门讲。你先记住这个默认结论容器删除的瞬间默认日志文件跟着一起没了。2. docker logs 查退出容器的适用边界与完整参数实操现在假设你已经确认容器处于Exited状态接下来就是具体怎么查日志的问题。docker logs的参数不少人只会用个-f其实在排查已退出容器时用好参数和用好命令本身同样重要。2.1 docker logs 基础用法tail、since、until、timestamps先列一下我实际排查中用到最多的参数参数作用典型场景-f实时跟踪输出容器还在运行观察日志持续输出--tail N只看最后 N 行容器刚崩溃看最后发生了什么--since只看某个时间点之后的日志和故障时间点对齐--until只看某个时间点之前的日志配合--since精确圈定时间段-t每行加上时间戳确认崩溃前日志的确切时间组合起来最常用的两条docker logs --tail 200 -t container_id排查崩溃问题时我一般先看尾部 200 行加上时间戳能直接看到“最后一条正常日志是什么时候”“崩溃前输出了什么”。如果要按时间范围精确拉取比如凌晨 3 点到 3 点半之间发生了什么docker logs --since 2025-01-15T03:00:00 --until 2025-01-15T03:30:00 -t container_id这里要给个提醒--since和--until只对日志文件里的时间戳生效如果容器日志本身很多这一步可能比较慢但用来定位故障点非常值。2.2 compose 管理下的容器日志怎么查用docker compose部署的服务查日志不要直接去翻底层的 container_id直接按服务名查命令更友好也更准确docker compose logs --tail 200 service_namedocker compose logs有几个隐藏亮点它会把同一个 compose 项目里多个服务的日志按时间合并输出这一点对排查服务间调用链特别有帮助还支持--no-color去掉颜色便于把输出粘贴到文档里-f同样可以实时跟踪。还有一个容易踩的坑如果你在项目目录外执行docker compose logs它可能找不到对应的 compose 文件报错说“no configuration file provided”。这时候要加-f指定 compose 文件或者先cd到项目目录再操作docker compose -f /opt/myapp/docker-compose.yml logs --tail 200 app2.3 日志驱动决定 docker logs 能不能用docker logs并不是万能的它能不能读到日志首先取决于容器用的日志驱动logging driver。默认情况下Docker 使用json-file驱动把标准输出信息写入一个 JSON 格式的日志文件docker logs读的就是它。但如果容器启动时指定了某些日志驱动情况就完全不同了。先用这条命令确认容器的日志驱动类型docker inspect --format {{.HostConfig.LogConfig.Type}} container_id正常情况下会返回json-file。如果返回的是journald那日志被写进了 systemd journaldocker logs依然可以读但从系统层面看也可以用journalctl直接查如果返回的是fluentd、gelf、awslogs这类远程转发驱动日志已经转发到外部系统了本地docker logs就不再展示如果返回的是none那么容器标准输出直接不记录docker logs什么都查不到。这个细节很关键因为很多人把容器迁移到云平台或自建集群后日志驱动被平台统一改成了journald或fluentd但排查问题时还死磕docker logs自然会觉得“日志丢了”。3. 退出码、inspect 字段与日志三件套一次完整崩溃根因排查前面讲的都是怎么把日志“调出来”但真正到排查一个容器为什么退出时只盯着日志是不够的。我习惯把“退出码 inspect 字段 日志”这三样配合起来用效率比单纯翻日志高得多。3.1 从 docker ps -a 的退出码开始读先看这一行docker ps -a | grep 容器名输出里会有一个Exited (N)括号里的数字就是退出码。退出码不是随意给的它是容器主进程退出时的状态码能直接反映出“进程是怎么死的”。退出码含义常见原因0正常退出任务执行完成不是故障1通用错误应用启动失败、初始化报错125docker run 自身错误参数错误、镜像拉取失败126命令无法调用可执行文件没有权限127命令找不到entrypoint 或 CMD 写错shell 找不到命令137SIGKILL被kill -9或 OOM 被杀139SIGSEGV段错误程序访问非法内存143SIGTERM收到终止信号常见于超时后 stop137是最值得警惕的一个因为它经常意味着容器被 OOM Killer 杀掉。但注意退出码是137只能说明收到了 SIGKILL具体是不是 OOM要看下一步。3.2 inspect 才是排查的“病历本”接着对退出容器执行docker inspect从里面找几个关键字段docker inspect --format ExitCode{{.State.ExitCode}} Error{{.State.Error}} OOMKilled{{.State.OOMKilled}} FinishedAt{{.State.FinishedAt}} container_idState.Error在很多情况下是空的但一旦有值基本就是 Docker 层面记录的退出原因State.OOMKilled是布尔值如果显示true那基本可以断定是内存超限被杀不用再从应用日志里白费力气找异常堆栈了FinishedAt记录了容器的确切退出时间可以和日志里的最后一条时间戳做对照确认“崩溃前有没有空窗期”。还有一个字段值得关注docker inspect --format {{.HostConfig.Memory}} container_id如果返回值是0说明容器没有设置内存限制如果是一个正整数那就要确认它是否接近内存上限。我遇到过不只一次内存泄漏问题现象都是容器每天固定时间 OOM日志里根本没有任何异常全靠OOMKilledtrue和内存监控锁定的问题。3.3 一个 MySQL 启动失败的真实现场举个例子之前一个 MySQL 容器启动失败停在Exited (1)。直接看输出docker logs --tail 30 mysql-test日志尾部关键信息是[ERROR] Cant start server: Bind on unix socket: Permission denied [ERROR] Do you already have another mysqld process running?第一反应可能是端口或 socket 权限问题但真正原因是容器内的 MySQL 数据目录权限不对。这时候直接结合退出码和 inspect 信息基本能确认不是被外部 kill 的而是应用自身初始化失败。排查路径就清晰了检查挂载卷的属主和权限而不是去查网络、查资源限制。这个例子说明日志只告诉你“哪里报错”退出码和 inspect 告诉你“进程为什么结束”三样拼在一起才能少走弯路。3.4 容器刚崩溃时docker events 也能帮上忙有时候你要排查的不是“已经退出很久的容器”而是“刚刚崩掉的那个”。如果当时没有看到控制台输出可以试一下docker eventsdocker events --since 30m它能输出最近 30 分钟内 Docker 守护进程记录的容器事件比如die、oom、stop等。尤其在集群环境里多个容器同时重启时用docker events可以快速确认容器是不是真的发生了 OOM 事件时间点和顺序都能对上。4. 容器被 rm 掉之后日志真的没救了吗这一章回答最开始同事那个问题容器已经被--rm删掉了日志还能不能找回来答案分几种情况但先说结论默认情况下很难非常依赖“当初怎么设计的”。4.1 docker rm 到底删了什么docker rm删除的是容器层包括容器对象本身、它的可写层、以及默认日志文件。默认json-file驱动下日志文件位于宿主机/var/lib/docker/containers/container_id/container_id-json.log如果你执行了docker rm这个目录默认会一起被清掉。docker system prune更狠它会顺带清理所有已停止容器很多人的日志就是这么“被消失”的。所以我一直强调如果你的容器没有做日志持久化那就默认它的日志生命周期和容器生命周期完全绑定。容器可以随手删但日志也会随手没。4.2 仅剩的抢救手段被占用文件与残留目录这里说两个不保证有效、但在极端场景下值得一试的抢救手段。第一种如果你删除容器之前某个进程还在持续读取这个日志文件比如你开着一个tail -f container_id-json.log即使文件被删了文件描述符还挂在进程上。这时候在 Linux 上可以用lsof L1找到被删除但仍被打开的文件lsof L1 | grep json.log如果找到了可以通过/proc/pid/fd/fd号把内容复制出来。但说实话这个操作窗口非常窄要求删除前后一直有进程读着那个文件现实中很少遇到。第二种在没有执行docker system prune的情况下容器目录可能还有残留可以去/var/lib/docker/containers/下碰碰运气sudo ls -lt /var/lib/docker/containers/按修改时间排序看看有没有刚删掉容器留下的目录。有的话进去看*-json.log还在不在。这个方法同样不保证有效因为docker rm会主动清理目录只是磁盘回收有延迟文件可能还残留在文件系统里。我必须说明这两种都属于“死马当活马医”我不建议你把它们当成正式手段。生产环境靠这种办法救日志本质上是运气好而不是方案对。4.3 救得回来的场景日志在挂载卷里真正救得回来的场景其实只有一个容器把日志写到了宿主机挂载目录或数据卷里。比如启动时用了docker run -d --name app \ -v /opt/app/logs:/app/logs \ myapp:latest这时候应用只要把日志写到容器内的/app/logs实际就是在写宿主机的/opt/app/logs。就算容器被删了、镜像被换了日志依然安安静静躺在宿主机上。这就是“日志生命周期脱离容器生命周期”的第一步。如果你的应用没有主动写文件只是打到了标准输出但你又想让标准输出日志落到宿主机文件可以考虑用--log-driver把输出重定向到一个文件型驱动或者干脆在容器外再套一层重定向。不过更通用的做法是下一章要说的日志驱动方案。5. 日志持久化四套方案别再等查不了日志才后悔到这里整篇文章的核心建议已经很明确了不要让日志的宿命和容器的生命周期绑死。下面这四套方案是我在不同项目里实际用过或对比过的每一套都有自己适合的场景也有各自的代价。5.1 方案一应用日志写挂载目录这是最直白、理解成本最低的方式。在容器启动或 compose 里把日志目录映射到宿主机应用自己落文件。docker run -d --name app \ -v /data/logs/app:/logs \ -e LOG_PATH/logs \ myapp:latestcompose 里对应这样写services: app: image: myapp:latest volumes: - /data/logs/app:/logs environment: - LOG_PATH/logs这套方案的优势是宿主机的日志就是普通文本文件tail、grep、logrotate随便用删掉容器完全不心疼。代价是要求应用本身支持把日志写到指定路径很多应用虽然默认打印到标准输出但配置里都支持日志文件路径需要你手动开启。5.2 方案二切换 journald 日志驱动如果你的宿主机本身就是 systemd 环境把容器日志驱动换成journald是很顺手的方案。启动时加参数docker run -d --name app \ --log-driver journald \ nginx之后查日志的方式就灵活了既可以用docker logs也可以用journalctl -u docker.service --since 30 min agojournald 的日志是集中管理的带索引、支持按时间范围精确查、还能用journalctl的各种过滤参数。它的优势是docker logs依然可用系统层面也能统一查适合单机服务较多的场景。劣势是journald 默认容量有限长期不清理也可能占用系统盘需要配合 journald 的SystemMaxUse做限制。5.3 方案三json-file 驱动配最大尺寸滚动这个方案不是把日志丢到容器外部而是确保默认的 JSON 日志文件不会无限增长把磁盘打满同时保留一定天数内的日志给排查留出窗口。修改 Docker 守护进程配置/etc/docker/daemon.json{ log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }改完重启 Dockersudo systemctl restart docker这样每个容器的日志文件最大 10MB最多保留 3 份也就是 30MB 左右超过的旧日志自动滚动删除。对于只关心“最近发生了什么”的排障场景这个配置通常够用。当然容器已经启动之后再来改全局配置是不会对已有容器生效的需要重新创建容器。compose 项目里也可以单独配置services: app: image: myapp:latest logging: driver: json-file options: max-size: 10m max-file: 35.4 方案四logspout 集中收集容器日志如果服务器上容器数量比较多或者你要把多台服务器的容器日志统一汇总手动进每台机器查日志的成本就很高了。这时候可以把日志推到统一的日志系统。比较轻量的做法是跑一个 logspout 容器它会自动监听 Docker socket把其他容器的标准输出转发到指定目标docker run -d --name logspout \ --volume/var/run/docker.sock:/var/run/docker.sock \ gliderlabs/logspout \ syslog://192.168.1.100:514这条命令把所有容器的标准输出转发到一个 syslog 服务器。你还可以换成logstash://、fluentd://等不同的目标协议。这样即使容器被删了日志早就被远端的日志系统收走了排障时去日志平台查就行彻底不依赖本机容器状态。5.5 四套方案怎么选方案学习成本运维成本适合场景应用日志写挂载目录低中单机部署、应用本身支持文件日志journald 日志驱动低低单机多容器宿主机是 systemdjson-file 滚动限制极低极低只要保留近期日志最简单实用logspout 集中收集中中容器数量多、需要远程汇总我个人在实际操作中的体会是不要只押注一套方案。最简单的情况至少把json-file的滚动限制配好保证日志不会打爆磁盘凡是面向业务的容器尽量让它把日志落一份到挂载卷到了多机或集群规模就提前把日志收集链路搭好别等问题发生在凌晨再爬起来翻/var/lib/docker/containers。按这个顺序把后路铺好再遇到“查看已退出docker容器的日志”这种需求时你手里的工具就远不止一个docker logs了。