容器日志暴涨是Docker json-file驱动默认不限制所致，需通过控大小、控数量、控源头三方面治理：定位大日志用inspect+ls或lsof；急救可truncate清空或update禁用日志；启动前应在run命令或daemon.json中配置max-size、max-file等参数；应用层须降噪，如调高日志级别、过滤无意义日志、避免异常循环刷屏。
容器日志暴涨不是配置遗漏，而是默认行为在生产环境下的必然结果。Docker 使用 json-file 驱动把所有 stdout/stderr 原样转成 JSON 写入本地文件，不设限就等于“无限追加”。关键不在删，而在控——控大小、控数量、控源头。
快速定位问题容器
别一上来就扫全量日志。先聚焦正在疯狂输出的容器：
- 查日志文件大小：用
docker inspect --format='{{.LogPath}}' <container_id></container_id>获取路径，再ls -lh看实际体积 - 批量检查所有容器日志：运行
docker ps -q | xargs -I {} sh -c 'echo "=== {} ==="; ls -lh $(docker inspect --format="{{.LogPath}}" {}) 2>/dev/null || echo "no log file"' - 结合进程看写入源：
lsof +D /var/lib/docker/containers 2>/dev/null | awk '$5 ~ /REG/ && $9 ~ /\.log$/ {print $2,$9}' | sort | uniq -c | sort -nr | head -5，找出占用句柄最多的 PID 和对应容器日志
运行时立即限流（急救）
发现某容器日志已超 2GB？先止血，再治本：
- 对单个容器日志清空（不中断服务）：
truncate -s 0 $(docker inspect --format='{{.LogPath}}' <container_id>)</container_id> - 批量清空所有容器日志：
find /var/lib/docker/containers/ -name "*.log" -exec truncate -s 0 {} \; - 临时关闭日志输出（慎用）：
docker update --log-driver=none <container_id></container_id>，之后可重新启用并配限值
启动前强制配置日志策略
靠事后清理是运维灾难。必须在容器启动阶段就固化限制：
- 运行时指定：
docker run --log-driver=json-file --log-opt max-size=50m --log-opt max-file=3 ... - 全局默认（推荐）：修改
/etc/docker/daemon.json，加入：{ "log-driver": "json-file", "log-opts": { "max-size": "50m", "max-file": "3", "compress": "true" } }重启 Docker：sudo systemctl restart docker，此后所有新容器自动继承 - 对已有容器生效：需
docker commit镜像后重新 run，或配合docker update（部分选项支持热更新）
源头治理：应用层降噪
容器日志暴增，80% 源于应用本身。光压日志文件没用，得压输出量：
- 禁用调试日志：Spring Boot 设置
logging.level.root=WARN；Node.js 应用关闭DEBUG=*环境变量 - 过滤高频无意义日志：Nginx 中加
log_not_found off;，避免每条 404 占一行；Java 应用用 Logback 的ThresholdFilter拦截 DEBUG 级别 - 检查异常循环：如数据库连接失败后每秒重试+打日志，应加退避机制或聚合告警，而非原样刷屏
