日志要限制大小，但也要先看为什么增长，不能只把文件截掉。

\n
容器日志太大，是 HomeLab 里很常见的磁盘问题。最容易做的事是清日志，最容易漏掉的事是问一句：它为什么会这么大？有一次我发现磁盘空间下降很快，最后不是日志轮转没配，而是一个服务因为路径错误不断重试，每分钟刷出大量异常。只清日志的话，几个小时后它还会长回来。

所以我会先定位增长来源，再决定轮转策略。日志轮转是护栏，不是修复。真正持续报错的服务，要先修异常，再限制大小。

json-file 要显式限制

Docker 默认常见的日志驱动是 json-file。如果不配置轮转，日志可能一直增长。单个服务可以在 Compose 里写：

services:
  noisy-app:
    image: example/noisy-app:1.0.0
    restart: unless-stopped
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

max-size 和 max-file 建议写成字符串。这里的意思是单个日志文件到 10 MB 左右轮转，最多保留 3 个文件。具体数字要按服务重要性调整：太小会丢排障上下文，太大又会浪费磁盘。

也可以在 Docker daemon 全局配置默认值，但要记住：已有容器通常不会自动采用新的默认日志配置，往往需要重建容器才能生效。改完配置后，要用 docker inspect 确认目标容器实际使用的 LogConfig。

local 驱动适合很多单机场景

local 日志驱动更适合单机 Docker 使用，默认带压缩和轮转，磁盘占用更可控。日常查看仍然用 docker logs，不要直接依赖它底层文件格式。

logging:
  driver: local
  options:
    max-size: "10m"
    max-file: "5"

如果没有外部日志采集系统，local 是一个很省心的选择。需要注意的是，换驱动后同样要重建容器，并确认你的管理面板或排障习惯仍然能正常查看日志。

先找最大日志，再读最近错误

我排查日志膨胀时会先看 Docker 总占用，再找大户：

docker system df
docker ps --format "table {{.Names}}\t{{.Status}}"
docker logs --tail=200 noisy-app
docker inspect noisy-app --format '{{json .HostConfig.LogConfig}}'
du -sh /var/lib/docker/containers/*/*-json.log 2>/dev/null

找到大日志后，不急着删除，先看最近 200 行。常见原因包括认证失败、配置路径不存在、外部服务超时、权限不足、定时任务循环、健康检查地址写错。日志增长也要看时间规律：是一直刷，还是每晚某个任务集中爆发。时间规律经常能指向真正的模块。

清理日志要谨慎

直接截断 Docker 管理的日志文件不是我的首选。短期可以救磁盘，但容易避开正常轮转，也会丢掉排障线索。更稳的方式是先停掉异常服务或修正配置，设置合理日志策略，重建容器，再观察增长速度。

如果空间已经很紧急，我也会先保存关键尾部日志：

docker logs --tail=500 noisy-app > noisy-app-error-snapshot.log

留住错误样本后，再做清理。否则清完以后只剩一个“磁盘满过”的结论，没有根因。

清理完成后，我会再等一个业务周期，看日志是否继续按同样速度增长。只有增长速度降下来，才说明处理真的有效。

我的日志策略

大多数普通服务，我会给 max-size: "10m"、max-file: "3" 或使用 local 驱动。关键服务会保留更多文件，方便回看升级前后的异常。特别吵的服务不靠把日志限制到很小来解决，而是先修掉异常来源。

日志的目标不是永远保存，也不是马上删除，而是在磁盘占用和排障信息之间取平衡。能看到最近错误，能限制最坏占用，能解释为什么增长，这套日志策略就算合格。