daemon.json 是唯一可靠的全局入口，因为 Docker 守护进程启动时仅读取一次该文件，所有后续创建的容器（无论通过 docker run、docker-compose up 还是 Kubernetes）均继承其中配置（如 log-driver 和 log-opts）；不修改它，单容器配置易被覆盖、忽略或在节点重启后失效。
必须改 /etc/docker/daemon.json，重启 Docker 守护进程才生效；只配容器或 Compose 不解决全局失控问题。
为什么 daemon.json 是唯一可靠的全局入口
Docker 守护进程启动时读取一次该文件，所有后续创建的容器（无论用 docker run、docker-compose up 还是 Kubernetes）都会继承其中的 log-driver 和 log-opts。不改这里，单个容器配置可能被覆盖、被忽略，或在节点重启后失效。
- 旧版 Docker（如 20.10 之前）对 Compose 的
logging支持不一致，容易 fallback 到无限制行为 -
docker run --log-opt只影响单次启动，无法约束 CI/CD 自动部署或 Operator 创建的容器 - 修改 daemon.json 后必须执行
sudo systemctl restart docker，否则配置不加载
max-size 和 max-file 必须成对出现
单独设 max-size 不会触发轮转，Docker 要求两个参数同时存在才启用切割逻辑。常见错误是只写 "max-size": "10m"，结果日志照常无限增长。
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
-
max-size推荐值：生产环境用"100m"～"500m"，避免单文件过大导致docker logs卡顿 -
max-file推荐值：设为"3"或"5"，总占用 =max-size × max-file，例如"100m"×"5"≈ 500MB 上限 - 单位必须带字母：
"10m"合法，"10"或"10MB"会被 Docker 忽略并退回到无限制模式
compress 在 json-file 驱动下无效，别白费劲
json-file 驱动不支持原生压缩，加 "compress": "true" 到 log-opts 里完全没效果——Docker 会静默忽略该字段，日志仍是明文。
- 真要压缩，得换驱动：
"log-driver": "local"，它原生支持compress: "gzip" - 但
local驱动不兼容某些日志采集工具（如旧版 Fluentd 插件），切换前需验证监控链路 - 如果坚持用
json-file，只能靠外部logrotate+cron补救，但有竞态风险（Docker 正在写日志时被 rotate）
验证是否真生效，别信“配了就完事”
改完 daemon.json 并重启 Docker 后，必须检查新容器是否真的继承了设置，而不是沿用旧缓存或 fallback 行为。
- 启动一个测试容器：
docker run -d --name logtest alpine:latest sh -c "while true; do echo 'log line'; sleep 1; done" - 查配置：
docker inspect logtest | jq '.[0].HostConfig.LogConfig'，确认输出里有"Type": "json-file"和对应"max-size"/"max-file" - 看实际日志文件：
ls -lh $(docker inspect --format='{{.LogPath}}' logtest)，等几分钟后重复执行，观察文件大小是否卡在max-size附近、且目录下出现-json.log.1等轮转文件
最易被忽略的是：daemon.json 修改后忘记重启 Docker，或者重启失败但没检查状态（systemctl status docker）。一旦守护进程没起来，所有容器都退回到默认无限制日志行为——磁盘爆满只是时间问题。
