docker logs 全参数用法#

docker logs 是最常用的查日志命令，但很多人只会最基础的 docker logs 容器名，把全部历史日志一股脑刷屏。其实它有一整套参数，组合好了定位问题非常快。

1
# 查看容器全部日志（标准输出 + 标准错误）
2
docker logs nginx
3

4
# 实时跟踪新日志，类似 tail -f，Ctrl+C 退出（不会停掉容器）
5
docker logs -f nginx

1
# 只看最后 100 行
2
docker logs --tail 100 nginx
3

4
# 和 -f 组合：先显示最后 50 行，再实时跟踪
5
docker logs -f --tail 50 nginx

1
# 看最近 10 分钟的日志
2
docker logs --since 10m nginx
3

4
# 看最近 1 小时的日志
5
docker logs --since 1h nginx
6

7
# 看某个时间点之后的日志（RFC3339 格式）
8
docker logs --since 2026-11-15T08:00:00 nginx
9

10
# 两个组合：看 08:00 到 09:00 这一小时的日志
11
docker logs --since 2026-11-15T08:00:00 --until 2026-11-15T09:00:00 nginx
12

13
# 看某个时间点之前的日志
14
docker logs --until 30m nginx

1
docker logs -t --tail 20 nginx

1
2026-11-15T00:12:31.123456789Z 192.168.1.10 - - "GET / HTTP/1.1" 200 612

1
docker logs --details nginx

1
# 只看标准错误（1 是 stdout，2 是 stderr；docker logs 默认两者都输出）
2
docker logs 容器名 2>/dev/null   # 只要标准输出
3
docker logs 容器名 1>/dev/null   # 只要标准错误
4

5
# 统计最近一小时 ERROR 出现了多少次
6
docker logs --since 1h 容器名 2>&1 | grep -c "ERROR"
7

8
# 按状态码粗筛访问日志（以 Nginx 为例，看所有 5xx）
9
docker logs --since 24h nginx 2>&1 | grep '" 5'
10

11
# 导出某天的完整日志留档
12
docker logs --since 2026-11-14T00:00:00 --until 2026-11-14T23:59:59 容器名 > nginx-1114.log 2>&1

容器日志到底存在哪#

理解日志的存放位置，才能理解轮转和磁盘占用的问题出在哪。

在默认的 json-file 日志驱动下，每个容器的日志都存在宿主机上一个固定的文件里：

1
/var/lib/docker/containers/<容器ID>/<容器ID>-json.log

查看某个容器日志文件的实际大小：

1
# 先拿到容器完整 ID
2
docker inspect -f '{{.Id}}' nginx
3

4
# 再看对应日志文件
5
ls -lh /var/lib/docker/containers/<容器ID>/<容器ID>-json.log

也可以一条命令直接定位：

1
docker inspect -f '{{.LogPath}}' nginx

json-file 驱动的工作原理很朴素：Docker 守护进程把容器的 stdout/stderr 一行一行包装成 JSON（每行包含日志内容、来源是 stdout 还是 stderr、时间戳），追加写进这个文件。docker logs 本质上就是把这个文件读出来、拆掉 JSON 包装再打印。

朴素的代价是：默认不做任何轮转。只要容器还在输出，这个文件就只会变大，永远不会自己变小。一个话痨容器（比如开了 debug 级别日志的服务）几天写出几十 GB 日志，是非常真实的事故——这正是下一节要解决的问题。

日志轮转：全局配置 daemon.json#

给所有容器统一设置日志上限，改的是 Docker 守护进程的配置文件 /etc/docker/daemon.json：

1
{
2
  "log-driver": "json-file",
3
  "log-opts": {
4
    "max-size": "20m",
5
    "max-file": "3"
6
  }
7
}

两个参数的含义：

• max-size: 20m：单个日志文件最大 20MB，写满了就滚动到下一个文件；
• max-file: 3：最多保留 3 个文件（当前文件 + 2 个历史文件）。

也就是说每个容器最多占用约 60MB 磁盘，写得再多也封顶，老日志自动丢弃。

改完之后要重启 Docker 守护进程才生效：

1
systemctl restart docker

验证配置是否被守护进程接受（改错 JSON 语法会导致 Docker 起不来，重启后先确认服务状态）：

1
systemctl status docker
2
docker info | grep -A2 "Logging Driver"

WARNING

最关键的坑：daemon.json 的日志配置只对「新建的容器」生效。 已经在跑的老容器，创建时用的是旧配置，重启 Docker、甚至重启容器本身都不会改变它的日志设置——必须把容器删除重建（docker compose up -d --force-recreate 或先 docker rm 再重新创建），新配置才套得上。所以改完 daemon.json 别急着以为万事大吉，逐个确认重要容器的实际配置：

1
docker inspect -f '{{.HostConfig.LogConfig}}' 容器名

输出里能看到该容器实际生效的 max-size 和 max-file，没有就说明它还是无限制状态。另外提醒一句：systemctl restart docker 会影响所有容器，没有配 live-restore 的话容器会被全部重启，请挑低峰期操作。

日志轮转：单容器配置（Compose）#

全局配置管所有容器，但有些容器你想区别对待：核心服务想多留点日志（max-file 给大些），一次性的小工具干脆少留。这时在 docker-compose.yml 里给单个服务写 logging 段，它会覆盖全局 daemon.json 的设置：

1
services:
2
  app:
3
    image: myapp:latest
4
    logging:
5
      driver: json-file
6
      options:
7
        max-size: "50m"
8
        max-file: "5"

这个服务就会按单文件 50MB、保留 5 个来轮转，总上限约 250MB，不受全局 20m×3 的影响。

用 docker run 时对应的是 --log-opt 参数，效果一样：

1
docker run -d \
2
  --log-driver json-file \
3
  --log-opt max-size=20m \
4
  --log-opt max-file=3 \
5
  nginx

两种写法的分工很简单：daemon.json 定基线，保证任何容器都不会写爆磁盘；compose 的 logging 段做个别调整，给需要特殊对待的服务开小灶。

其他日志驱动对比#

json-file 不是唯一选择。Docker 还内置了几种日志驱动，适用场景各不相同：

几点说明：

• local 驱动值得多看一眼：它就是为解决 json-file 的毛病设计的，默认就带轮转（max-size 默认 20m、max-file 默认 5），还做了压缩和更高效的读写。新部署的机器可以直接把 daemon.json 的 log-driver 换成 local，省去手动配轮转。
• journald 的好处是能按容器名过滤查看，坏处是日志和系统日志混在一起，且 journal 本身也有自己的轮转策略要管。用了 journald 之后，除了 docker logs，还可以直接在宿主机上按容器名查：

1
journalctl CONTAINER_NAME=nginx -f

• local 驱动多提一句：它的日志文件不在前面说的 -json.log 路径下，格式也是二进制优化过的，不能直接用文本工具去翻文件，老老实实用 docker logs 看就行。它省下的主要是磁盘 I/O 和空间，对日志量大的机器收益明显。
• syslog 驱动下 docker logs 完全失效，日志只在 syslog 里，换机器排障时容易两眼一抹黑。

WARNING

none 驱动是个大坑预警：设成 none 后容器日志被直接丢弃，docker logs 执行不报错、但什么都输出不了。哪天你发现某个容器「日志功能坏了」，先用 docker inspect -f '{{.HostConfig.LogConfig.Type}}' 容器名 查一下它到底用的什么驱动——十有八九是创建时被设成了 none，或者是从别人那抄的 compose 文件里带着这个设置。

磁盘被日志写满：排障全流程#

这是 Docker 新手最容易吃的一次亏：服务器突然各种服务报错、数据库连不上、SSH 登录都变慢，最后发现是根分区 100% 满了，而凶手往往就是某个容器的日志。按这个流程走，十分钟能定位并止血。

1
# 看分区使用率，确认哪个分区满了（一般是 / 或 /var）
2
df -h
3

4
# 看 /var/lib/docker 占了多少
5
du -sh /var/lib/docker

1
# 按容器列出占用，排序找最大的
2
du -sh /var/lib/docker/containers/* | sort -rh | head -20
3

4
# 或者直接找所有超过 100MB 的日志文件
5
find /var/lib/docker -name "*-json.log" -size +100M -exec ls -lh {} \;

1
docker ps -a --no-trunc | grep <容器ID前几位>

1
truncate -s 0 /var/lib/docker/containers/<容器ID>/<容器ID>-json.log

1
cat /dev/null > /var/lib/docker/containers/<容器ID>/<容器ID>-json.log

1
docker restart 容器名

1
#!/bin/bash
2
# /opt/scripts/check-docker-logs.sh：找出超过 500MB 的容器日志并记录
3
find /var/lib/docker/containers -name "*-json.log" -size +500M \
4
  -exec ls -lh {} \; >> /var/log/docker-logs-check.log 2>&1

1
0 9 * * 1 /opt/scripts/check-docker-logs.sh

Dozzle：网页端集中看日志#

容器一多，SSH 上去一个个 docker logs 就很折腾了。Dozzle 是一个轻量的日志查看 Web 界面：实时流式显示所有容器的日志、支持搜索过滤、多容器一键切换，镜像本身只有十几 MB，是个人服务器上最顺手的日志工具。

1
services:
2
  dozzle:
3
    image: amir20/dozzle:latest
4
    container_name: dozzle
5
    restart: unless-stopped
6
    environment:
7
      - TZ=Asia/Shanghai
8
    volumes:
9
      - /var/run/docker.sock:/var/run/docker.sock:ro
10
    ports:
11
      - "127.0.0.1:8080:8080"

1
docker compose up -d

1
    command: --filter label=com.centurylinklabs.watchtower.enable=true

1
    command: --filter name=nginx --filter name=app

1
    environment:
2
      - DOZZLE_BASE=/logs

1
# 在自己电脑上开隧道，然后浏览器访问 http://localhost:8080
2
ssh -L 8080:127.0.0.1:8080 root@你的服务器

1
    environment:
2
      - TZ=Asia/Shanghai
3
      - DOZZLE_USERNAME=admin
4
      - DOZZLE_PASSWORD=换成你的强密码

排障：docker logs 没输出怎么办#

docker logs 执行成功、退出码正常，但就是一片空白。按可能性从高到低排查：

1. 应用把日志写进了文件，没走 stdout/stderr。 这是最常见的原因。docker logs 只能拿到容器主进程的标准输出和标准错误；很多传统应用默认把日志写到 /var/log/xxx.log 这类文件里，自然看不到。验证方法：进容器里看看有没有日志文件在长大：

1
docker exec -it 容器名 sh -c 'ls -lt /var/log/ | head'

解决办法是改应用的日志配置让它输出到 stdout；实在改不了，可以在启动命令里把日志文件软链到标准输出，这也是很多官方镜像的做法：

1
RUN ln -sf /dev/stdout /var/log/app.log \
2
    && ln -sf /dev/stderr /var/log/app-error.log

2. 日志驱动被设成了 none。 前面提过，none 驱动直接丢弃日志。检查并重建容器换回 json-file 或 local：

1
docker inspect -f '{{.HostConfig.LogConfig.Type}}' 容器名

3. 容器已经删除了。 日志文件是跟着容器走的，容器被 docker rm（或者被自动更新工具重建失败后清掉）之后，日志文件一并删除，事后无从查起。这也是为什么 《如何在Linux自动更新Docker容器》 里建议重要服务先开「只监控」观察期、更新前先看日志：真出了事，旧容器的日志还在才有据可查。需要长期留存的日志，应该让应用输出到挂载出来的数据卷文件里，或者接入集中日志系统，而不是只依赖 docker logs。

4. 用了 —since 却把时间算错了。 不加参数明明有日志，一加 --since 就空白，多半是时间对不上：docker logs 的绝对时间按 UTC 理解，而你脑子里想的是北京时间，差着 8 小时，窗口自然卡空了。不确定时先用相对时长（--since 30m）验证，或者用 date -u 看一眼服务器的 UTC 时间再换算。

5. 顺带一提：输出被缓冲了。 有些语言（典型如 Python）的 stdout 在非终端环境下是块缓冲，程序在跑、日志却攒着不吐出来，看起来像没输出，过一阵又突然刷出一大片。这不是 Docker 的问题：Python 加 -u 参数或环境变量 PYTHONUNBUFFERED=1 即可，其他语言同理查各自的无缓冲设置。

再往后：什么时候需要集中日志系统#

本篇讲的都是单机范围内的日志管理：一台机器、几十个容器，docker logs 加 Dozzle 完全够用。但如果你的情况变成下面这样，就该考虑把日志集中收集到专门的系统里了：

• 机器变多：三五台服务器各跑各的容器，出一次问题要挨个 SSH 上去翻日志，效率太低；
• 日志要长期留存：审计、复盘需要查几个月前的日志，而本机轮转早就把它们挤掉了；
• 需要告警：想在日志出现特定错误（比如支付失败、异常堆栈）时第一时间收到通知，而不是等用户来报障。

常见的集中方案有 Loki + Promtail + Grafana（轻量，和监控面板能合一）、ELK（Elasticsearch + Logstash + Kibana，功能强但吃资源）等。它们的共同思路是：在每台机器上跑一个采集小组件，把容器日志实时转发到中心存储。个人规模建议从 Loki 起步，资源占用小、和 Docker 的配合也成熟。不过记住一句话：集中系统是锦上添花，单机的轮转配置永远是地基——采集组件挂掉的时候，本机日志如果没封顶，照样能把磁盘写满，地基的活儿一天都不能省。

小结#

• docker logs 的日常组合是 -f 跟踪、--tail 限量、--since/--until 卡时间窗、-t 带时间戳，先缩小范围再细看；
• 默认 json-file 驱动不轮转，这是磁盘写满事故的头号来源，必须配轮转：daemon.json 全局设 max-size: 20m + max-file: 3 定基线，compose 的 logging 段给个别容器开小灶；
• 牢记 daemon.json 改完只对新建容器生效，老容器要重建，并用 docker inspect 逐个验证；
• 磁盘真被写满时，流程是 df/du/find 定位 → truncate -s 0 清零止血（绝不能直接 rm）→ 补轮转配置防复发；
• 容器多了用 Dozzle 在网页上集中看日志，但 docker.sock 事关宿主机 root 权限：只读挂载、端口绑 127.0.0.1、开登录认证，三件套缺一不可；
• docker logs 没输出，先怀疑应用没往 stdout 写，其次查日志驱动是不是 none，最后确认容器是不是已经被删了。

日志管理的核心就一句话：平时给它封顶，出事时靠它查命。轮转配置花十分钟一次配好，往后每次排障都会感谢现在的自己。