本质是日志高频写入触发宿主机文件系统层句柄泄漏，需通过释放dockerd卡住的-json.log句柄、定位刷日志容器、配置local日志驱动及限制max-size/max-file、确保异步日志正确关闭等措施根治。
这个问题本质是“日志高频写入”触发了宿主机文件系统层的句柄泄漏或未释放，不是单纯调大 ulimit 就能解决的。关键在于：临时日志（比如调试用的 trace 日志、循环打印的 INFO、未关闭的 logger 实例）会持续创建新文件、打开新 fd，而容器或日志驱动若未正确复用或清理，就会让宿主机的 /var/lib/docker/containers/*-json.log 文件句柄长期滞留，最终拖垮 dockerd 或整个系统。
快速止血：立刻释放被卡住的日志句柄
别等容器重启——很多情况下，是 dockerd 进程自己卡住了日志文件的 fd，导致无法轮转或 close：
- 查 dockerd 当前打开的句柄数：
ls /proc/$(pgrep dockerd)/fd | wc -l，若 >5w 且持续上涨，基本确认是它在“漏” - 用
lsof -p $(pgrep dockerd) | grep json.log | head -10看是否大量重复指向同一个容器的-json.log文件（说明该容器日志写入异常，但 dockerd 没释放句柄） - 临时释放：找到对应容器 ID 的日志文件路径（如
/var/lib/docker/containers/abc123.../abc123...-json.log），执行lsof -t -Fp /path/to/file | xargs -r kill -HUP向 dockerd 发送 HUP 信号促使其重载日志句柄（比直接 kill 安全）
定位刷日志源头容器
高频临时日志往往来自某几个“失控”容器，不是所有容器都参与：
- 用
docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.NetIO}}" | sort -k4 -hr | head -5找出网络 I/O 最高者——日志刷得多，写磁盘和 socket 都会拉高 NetIO - 进可疑容器执行：
find /tmp /var/log -type f -name "*.log" -mmin -5 | xargs ls -lh 2>/dev/null，看是否有 5 分钟内猛增的临时日志文件 - 检查应用是否启用了 debug/trace 日志且没关：Java 查
jinfo -flag +PrintGCDetails $(pgrep java)类似逻辑；Node.js 查process.env.DEBUG是否开启；Python 查logging.getLogger().level
从配置上切断高频日志链路
光靠应用改代码太慢，必须在容器启动时就设好“防护网”：
- 强制限制单容器日志输出速率（Docker 20.10+ 支持）：
docker run --log-opt max-size=5m --log-opt max-file=2 --log-opt labels=env=prod ...，避免单个容器把磁盘和句柄全占满 - 禁用 json-file 驱动的默认行为：在
/etc/docker/daemon.json中加"log-driver": "local"，local 驱动更轻量、支持压缩、不依赖大量 fd，且默认启用自动轮转 - Docker Compose 中对问题服务单独加固：
logging: driver: "local" options: max-size: "5m" max-file: "2" compress: "true"
根治：让日志变“可回收”，而非“只写不放”
临时日志本身不可怕，可怕的是它变成“僵尸句柄”。真正要做的，是确保每次写入后资源能归还：
- 检查应用是否使用了异步日志框架（如 log4j2 AsyncLogger、zap.NewTee），确认其
Stop()或Sync()被正确调用，否则 shutdown 时 fd 不释放 - 避免在循环里 new logger 实例：统一用 singleton 或 context-aware logger，防止每轮迭代都 open 新 fd
- 对调试类临时日志，改用
stderr重定向到/dev/null（如command: sh -c 'your-app 2>/dev/null'），绕过 docker 日志驱动捕获，彻底不占句柄
