docker日志管理核心是受控轮转+有限保留+可靠清理，通过json-file驱动的max-size和max-file参数实现；支持容器级、全局daemon.json、compose三种配置方式，并可用truncate安全清空大日志。
Docker 容器日志归档与清理的核心不是“归档”，而是受控轮转 + 有限保留 + 可靠清理。Docker 本身不提供传统意义上的日志归档（如压缩存档、远程归档），它通过 json-file 驱动的轮转机制实现“逻辑归档”——旧日志文件被自动重命名、覆盖或删除，从而控制磁盘占用。
关键在于：配置 max-size 和 max-file，并选对作用层级（容器级 or 全局）
容器启动时单独配置（推荐用于关键服务）
适合对特定容器精细化控制，比如高日志量的 API 服务或调试中的中间件。
docker run -d \ --log-driver json-file \ --log-opt max-size=20m \ --log-opt max-file=5 \ --name myapp \ nginx:alpine
-
max-size=20m：单个日志文件达到 20MB 后触发轮转 -
max-file=5：最多保留 5 个日志文件（含当前正在写的那个），超出后最老的被删除 - 日志路径仍为
/var/lib/docker/containers/<id>/<id>-json.log</id></id>，轮转后生成类似<id>-json.log.1</id>、.2的文件
✅ 优点：灵活、无需重启 Docker daemon；❌ 缺点：每次
docker run都要重复写，易遗漏。
全局统一配置（推荐用于生产环境标准化）
修改 Docker 守护进程配置，让所有新创建的容器默认生效，避免逐个配置疏漏。
编辑 /etc/docker/daemon.json（若不存在则新建）：
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}
保存后重启 Docker：
sudo systemctl restart docker
- 所有后续
docker run创建的容器都会继承该策略 - 已运行的容器不受影响（需重建或
docker update不支持日志选项，所以必须重启容器才能生效） - 可配合
docker inspect <container></container>验证是否应用：
docker inspect myapp --format='{{.HostConfig.LogConfig}}'
# 输出示例：{json-file map[max-file:3 max-size:10m]}
Compose 场景下配置（微服务/本地开发常用）
在 docker-compose.yml 中为服务指定日志策略，清晰、可版本化：
version: '3.8'
services:
api:
image: my-api:v1
logging:
driver: "json-file"
options:
max-size: "15m"
max-file: "4"
db:
image: postgres:15
logging:
driver: "none" # 关键服务如数据库，若无需 stdout 日志，可直接禁用
-
driver: "none"是有效减负手段：PostgreSQL、Redis 等自身已写文件日志，Docker 捕获 stdout 反而冗余且占空间 - 每个 service 可独立设置，适配不同日志强度
补充：临时清理已有大日志（应急用）
当发现某容器日志已达数十 GB，又不能立即重启时，可安全清空（不中断容器）：
# 获取日志路径
LOG_PATH=$(docker inspect myapp --format='{{.LogPath}}')
# 安全清空（保留文件句柄，Docker 继续写入）
sudo truncate -s 0 "$LOG_PATH"
# 或等效命令（需 root）
sudo sh -c "> $LOG_PATH"
⚠️ 注意：
- 不要用
rm删除日志文件（Docker 会因文件丢失报错或停止写日志） -
truncate或重定向>是唯一安全方式 - 清空后日志从头开始写，原
.1,.2等轮转文件仍存在，但不再新增
日志清理的本质是预防而非补救。设好 max-size 和 max-file，再搭配 logging: driver: none 对非必要容器关闭日志，基本就覆盖了 95% 的场景。
