Docker会将容器内进程写到标准输出和标准错误的数据，按照预先设定的日志驱动进行处理与存储。不同的日志驱动在性能、磁盘占用、可观测性方面表现差异很大。默认情况下Docker采用json-file驱动，把每行日志封装成JSON对象落盘，这种格式方便人工查看，但缺少自动清理机制。
一、Docker支持的常用日志驱动
Docker引擎内置了多种日志驱动，可以通过命令docker info | grep Logging查看当前默认驱动。最典型的包括json-file、local、syslog、journald、fluentd、awslogs等。每种驱动背后对应一套日志转发或存储逻辑，并非所有驱动都适合在单机高密度部署场景下使用。
json-file驱动将日志以JSON行形式写入宿主机的/var/lib/docker/containers/<id>/<id>-json.log文件，优点是兼容性好、可直接tail查看；缺点是不配置轮转时文件无限增长。local驱动则从Docker 17.05引入，使用私有格式并内建文件大小与数量限制，更适合生产环境长期运行。syslog与fluentd则把日志通过网络发给外部收集系统，自身不在本地留存大量数据。
1.1 驱动选择的核心考量
选择日志驱动时要同时考虑磁盘压力、排查便利性和日志集中化需求。如果容器数量少且需要频繁登录机器看日志，json-file加限制参数最直观。如果宿主机磁盘小、容器多，local驱动能显著降低运维风险。当团队已经搭建了ELK或日志服务，使用fluentd驱动避免二次采集是更优架构。
需要注意，日志驱动是在Docker daemon级别或容器级别配置的，daemon级配置影响所有未单独指定的容器。容器启动时通过--log-driver与--log-opt传入的参数优先级高于全局配置，这让我们能针对个别 noisy 容器做特殊处理。
二、通过daemon.json全局配置日志驱动
修改/etc/docker/daemon.json是最常用的全局配置方式。该文件是Docker守护进程的启动配置，修改后需执行systemctl restart docker生效。下面的示例将默认驱动改为local，并限制每个容器最多保留3个文件、单文件10MB。
{
"log-driver": "local",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}
如果使用json-file驱动并想避免磁盘爆满，同样可以加入限制参数，只是文件仍是明文JSON。示例如下，限制单文件50MB、保留5个文件，超出后Docker自动轮转并删除最旧文件。
{
"log-driver": "json-file",
"log-opts": {
"max-size": "50m",
"max-file": "5"
}
}全局配置的优点是一次设定、全部受益，不必改动既有容器的启动脚本。但它的局限在于无法为不同业务容器设定不同策略，且修改后只对新创建容器生效，旧容器需要重建才能套用新驱动。
2.1 配置参数含义解析
max-size定义单个日志文件达到多大时触发轮转，支持k、m、g单位。若不设，json-file默认不限制。max-file设定保留的文件总数，包含正在写入的那个，轮转超出数量后旧文件被删除。对于local驱动，还有compress参数可开启压缩进一步省空间。
需要提醒的是，log-opts里的键名取决于具体驱动，例如fluentd驱动使用fluentd-address而非通用参数。配置错误会导致Docker守护进程启动失败，因此改动daemon.json前建议先执行dockerd --validate做静态校验。
三、容器级日志驱动配置示例
当某个特定容器日志量远超其他服务，可以在docker run时单独指定驱动。以下命令启动一个Nginx容器，使用json-file驱动并收紧到单文件20MB、保留2份，避免其访问日志把磁盘写满。
docker run -d
--name nginx-demo
--log-driver json-file
--log-opt max-size=20m
--log-opt max-file=2
-p 8080:80
nginx:stable对于需要把日志直送远程收集器的场景，可采用fluentd驱动。下面示例将容器日志发往本机24224端口的Fluentd，并打上服务标签便于后端过滤。
docker run -d
--name app-logtest
--log-driver fluentd
--log-opt fluentd-address=127.0.0.1:24224
--log-opt tag=docker.app.demo
busybox echo "hello logging"容器级配置让运维能精细控制，但也增加了编排文件的复杂度。在Kubernetes环境中，则要通过Pod的logging相关注解或DaemonSet采集而非依赖Docker驱动，这一点与单机Docker使用习惯不同。
3.1 查看与验证当前容器日志驱动
配置完成后，可用docker inspect确认某个容器实际采用的驱动与参数。重点关注HostConfig.LogConfig字段，它会显示Type与Config。若发现与预期不符，通常是daemon重启未生效或启动命令被覆盖。
docker inspect -f '{{.HostConfig.LogConfig}}' nginx-demo这条命令会输出类似{json-file map[max-file:2 max-size:20m]}的结果。通过比对，我们能快速定位为什么某容器依旧产生超大日志文件，例如因为max-size单位写成了mb而非m导致解析失效。
四、常见误区与磁盘保护建议
不少人在磁盘报警后才去删-json.log文件，但直接rm并不能释放空间，因为文件句柄仍被Docker持有。正确做法是配合轮转配置，或用truncate -s 0清空文件，再视情况重启容器释放句柄。
另一个误区是认为换了local驱动就绝对安全。local虽带限制，但如果max-file设得过大、单文件也大，在极端日志爆发时仍可能短期占满磁盘。因此建议配合监控告警，对/var/lib/docker所在分区做容量巡检。
4.1 驱动迁移与历史日志处理
从json-file迁到local驱动时，旧容器历史日志不会自动转换格式。需要先将容器日志目录归档，再删除容器并以新驱动重建。若业务不允许中断，可采用蓝绿部署：新版本容器用local驱动启动，验证后下线旧容器。
总结来看，Docker日志驱动配置不是一次性动作，而是随业务规模演进的持续调优过程。理清驱动差异、用好全局与容器级参数、建立容量监控，才能从根本上避免日志把系统盘撑爆的事故。