日志驱动决定什么
日志驱动决定 docker logs 是否可用：json-file 与 local 支持容器级日志查看与轮转，journald、syslog 等要把查询交给对应后端，none 则完全没有输出。驱动在容器创建时确定，改守护进程默认值只影响新容器。
基本信息
| 支持 docker logs | json-file、local |
|---|---|
| 例外交给后端 | journald 对应 journalctl，syslog 对应系统日志服务 |
| 查看默认驱动 | docker info 的 Logging Driver |
| 查看容器驱动 | docker inspect 的 HostConfig.LogConfig.Type |
| 生效时机 | 容器创建时确定，改动需重建容器 |
典型使用场景
- 排障时 docker logs 没有输出，先确认当前用的驱动
- 接入集中日志系统时确定驱动与采集方式
- 评估轮转策略，避免文件型驱动把宿主磁盘写满
- 迁移日志方案前梳理存量容器的驱动差异
- 交接文档里记录日志查看入口，降低接手成本
确认驱动与查询
确认驱动与查询
docker info -f '{{.LoggingDriver}}' # 守护进程默认驱动
docker inspect -f '{{.HostConfig.LogConfig.Type}}' web # 单个容器的驱动
journalctl CONTAINER_NAME=web -n 30 --no-pager # journald 后端的查询方式
docker logs --tail 50 web # 支持容器级日志时使用常见驱动的差异
| 驱动 | docker logs | 查询入口 |
|---|---|---|
| json-file | 可用 | docker logs，文件落在宿主日志目录 |
| local | 可用 | docker logs，二进制格式文件 |
| journald | 不可用 | journalctl 按容器名过滤 |
| syslog | 不可用 | 转发到系统日志服务 |
驱动在容器创建时确定，改守护进程默认值只影响新容器，存量容器要重建才能切换。
换成 journald 后 docker logs 变空属于预期行为，交接时要写进说明，避免被当成故障排查。
日志不轮转会把宿主磁盘写满，使用文件型驱动时要配置轮转参数，容器数量多时尤其重要。
集中采集方案通常在宿主侧读取日志文件或订阅系统日志，选驱动时要和采集方式一起决定。
排障入口不统一会明显拉长处理时间，团队里最好约定一种查询方式，并把例外情况写进文档。
同一宿主上不同容器可以使用不同驱动，排查日志前按容器逐个确认实际驱动，而不是只看守护进程的默认值。