应设max-size=5m～10m、max-file≥3，配合compress=true及宿主机logrotate兜底，避免高频日志空窗期爆盘。
json-file 驱动的 max-size 和 max-file 到底怎么设才不爆盘
直接设 max-size=10m 和 max-file=5 看似稳妥，但实际可能仍导致磁盘打满——因为 Docker 默认不限制日志写入速率，高频小日志（如每秒上千行 debug 日志）会快速填满单个文件，而轮转又依赖文件“写满”触发，中间存在空窗期。
实操建议：
-
max-size建议设为5m～10m，避免单文件过大影响docker logs查看性能 -
max-file不宜低于3，否则旧日志被覆盖过快，故障排查时已丢失关键上下文 - 若应用日志量极不稳定，可加
--log-opt compress=true减少磁盘占用（注意：压缩后docker logs无法直接读取 .1.gz 文件） - 必须配合宿主机级
logrotate做兜底，尤其在max-size未生效的极端场景下（如容器崩溃前疯狂刷屏）
syslog 驱动里 syslog-address 写错端口或协议会静默丢日志
syslog 驱动不会校验远端服务是否可达，syslog-address=udp://192.168.1.100:514 写成 tcp:// 却没开 TCP 监听，或端口写错，结果就是容器照常启动、docker logs 能查到缓存（如果有的话），但日志根本没发出去——且无任何错误提示。
验证方式：
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- 先在宿主机用
nc -u 192.168.1.100 514测试 UDP 连通性（TCP 同理） - 启动容器后，立刻执行
docker inspect <容器名> | jq '.[0].HostConfig.LogConfig'，确认syslog-address值已正确注入 - 在 syslog 服务端（如 rsyslog）配置中启用
$DebugLevel 2并查/var/log/syslog，看是否有连接拒绝或解析失败记录
journald 驱动在非 systemd 系统上直接失效
journald 驱动强依赖宿主机运行 systemd 且 systemd-journald 服务处于 active 状态。在 CentOS 7+、Ubuntu 16.04+ 默认可用，但在 Alpine、Debian 10（未启用 systemd）、或 WSL2 的默认发行版里，docker run --log-driver=journald 会静默回退到 json-file，且 docker inspect 显示的仍是 journald，造成误判。
判断是否真生效：
- 执行
systemctl is-active systemd-journald，必须返回active - 运行容器后，执行
journalctl CONTAINER_NAME=<容器名>，有输出才算成功；若报No journal files were found，说明驱动未真正接入 - 注意：
journalctl查日志时，CONTAINER_NAME是容器启动时的 name，不是 ID，且大小写敏感
全局配置 daemon.json 后容器不生效的三个常见原因
改完 /etc/docker/daemon.json 并 systemctl restart docker，新容器仍走默认配置？大概率卡在这三处：
- 容器是用
docker-compose.yml启动的，且该文件里显式写了logging:块——它会覆盖 daemon.json 全局设置 - Docker Desktop（macOS/Windows）用户改的是
%programdata%\docker\config\daemon.json，但 GUI 设置里「Docker Engine」面板又手动覆盖了 log-driver，后者优先级更高 - 已有容器不会自动继承新配置，必须
docker rm -f <容器>后重建，docker start不触发日志驱动重协商
最易被忽略的一点：OCI 运行时（如 runc）只在容器创建阶段读取日志驱动配置，之后任何 daemon.json 修改、甚至 dockerd 重启，都不会影响正在运行的容器日志路径或行为。
