在 docker-compose.yml 中需在服务下配置 logging 块,使用 json-file 驱动并设 max-size="10m"(带单位字符串)和 max-file="3"(纯数字字符串),二者共同控制日志轮转大小与保留数量。

docker-compose.yml 里怎么配 max-size 和 max-file
直接在服务定义下加 logging 块,用 json-file 驱动并指定两个关键选项即可。Docker 默认就是 json-file,但显式写出更稳妥,避免被其他配置覆盖。
常见错误是把 max-size 写成数字(如 10)或带空格(如 "10 m"),必须是带单位的字符串,比如 "10m"、"100k"、"1g";max-file 必须是纯数字字符串,如 "5",不能写 5(YAML 会解析为整数,部分 Docker 版本不认)。
-
max-size控制单个*-json.log文件体积上限,达到即触发轮转 -
max-file是保留的总文件数(含当前正在写的那个),超出后最旧的.1、.2等会被删除 - 轮转不依赖时间,只看文件大小是否达标;日志内容不会丢,只是切分归档
services:
api:
image: myapp:latest
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "3"
docker run 启动时怎么加日志限制
用 --log-driver 和 --log-opt 显式传参,适合调试或临时运行容器。注意参数顺序:驱动必须先于选项,且每个 --log-opt 只能带一个键值对。
容易踩的坑是漏掉 --log-driver json-file —— 如果宿主机 daemon.json 里改过全局驱动(比如设成了 syslog),那不显式指定,--log-opt 就完全无效。
Miller (mlr) 是一个命令行工具,用于查询、整形和重新格式化名称索引数据,如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
-
--log-driver json-file必须显式声明,否则--log-opt不生效 -
--log-opt max-size=10m和--log-opt max-file=3要分开写,不能合并 - 单位不区分大小写(
m和M都行),但推荐小写,和官方文档一致
docker run -d \ --name api-dev \ --log-driver json-file \ --log-opt max-size=10m \ --log-opt max-file=3 \ myapp:latest
为什么改了 daemon.json 但老容器没生效
全局配置只影响新创建的容器。已运行的容器日志配置在启动时就固化进容器元数据里了,重启也不重读 daemon.json。
验证方式很简单:执行 docker inspect <container_id> | grep -A 5 "LogConfig"</container_id>,看输出里的 MaxSize 和 MaxFile 是否是你设的值。如果不是,说明配置没打到这个容器上。
- 已运行容器想生效?只能
docker stop && docker rm后重新run或up - daemon.json 修改后必须
sudo systemctl restart docker,否则配置压根不加载 - 如果
docker info | grep "Logging Driver"显示的不是json-file,说明 daemon.json 有语法错误或路径不对
max-size 设多大才合理
没有通用答案,取决于你的日志密度和磁盘余量。10MB 是生产环境较常见的起点,但要注意:它控制的是单个文件大小,不是总日志量 —— max-file: "3" 意味着最多占 30MB,而高频服务可能几分钟就写满一个 10MB 文件。
真正容易被忽略的是日志内容本身。如果应用疯狂打 DEBUG 级别日志,再小的 max-size 也扛不住;反过来,如果只打关键错误,100MB 也够用很久。所以优先从应用侧收敛日志级别,再用 max-size 做兜底。
- 低频服务(如定时任务):可设
"100m"+"5" - 高频 API 服务:建议
"5m"~"10m"+"3",避免单次轮转卡顿 - 测试环境可放宽,但别关掉 —— 日志失控往往从开发机开始










