应监控 inode 使用率而非仅磁盘空间，因 Docker overlay2 的海量小文件易耗尽 inode；需对 /var/lib/docker 挂载点设 85%/92%/100% 三档告警，结合 Prometheus 或 Zabbix 采集指标，并从构建缓存限制、d_type 启用、定期清理及独立分区调优 inode 密度等源头防控。
直接看 inode 使用率，比等报错再救火更可靠。Docker 镜像层（尤其是 overlay2 的 lowerdir/upperdir）由海量小文件构成，每个 layer 元数据、每个临时文件、每个构建缓存条目都占一个 inode。一旦 inode 耗尽，no space left on device 就会出现在磁盘还有 20% 空间的时候——这不是空间问题，是索引资源枯竭。
把 df -i 接入实时监控并设分级告警
不能只靠人工 df -i，必须让系统主动感知：
- 对
/var/lib/docker所在挂载点（通常是/或单独的/var分区）设置三档阈值：85% 发邮件标记风险，92% 触发钉钉强提醒并自动执行du --inodes -S /var/lib/docker | sort -nr | head -10定位热点目录，100% 立即挂载为只读 + 记录快照 - 使用 Prometheus + node_exporter 时，可通过
node_filesystem_files_free{mountpoint="/var/lib/docker"}和node_filesystem_files{...}计算使用率，避免依赖 shell 解析文本 - Zabbix 用户可配置自定义 key：
system.run[df -i /var/lib/docker | tail -1 | awk '{print $5}' | sed 's/%//']，再设触发器
识别镜像层相关的高危 inode 模式
Docker 的 inode 消耗不是均匀的，要盯住几个典型路径和行为：
-
/var/lib/docker/overlay2下大量以随机字符串命名的目录（如abc123def.../diff），且每个目录里有数百个零字节或几 KB 的配置文件、.wh. 文件、json 元数据 - 同一时间戳集中创建：用
find /var/lib/docker/overlay2 -type d -newermt "2026-06-17 14:00" ! -newermt "2026-06-17 14:05" | wc -l查最近 5 分钟新建了多少 layer 目录 - 悬空镜像残留：运行
docker images -f "dangling=true" -q | xargs -r docker image rm后，find /var/lib/docker/overlay2 -maxdepth 1 -type d -name "*-init" | wc -l若仍超 50，说明清理未彻底
在 Docker daemon 层加固 inode 防御
光监控不够，得从源头控制增长节奏：
- 启用构建缓存限制：在
/etc/docker/daemon.json中添加"builder": {"gc": {"defaultKeepStorage": "20GB"}}，避免 buildkit 无限堆积中间层 - 禁用无用存储驱动特性：确认 overlay2 已启用
d_type=true（stat -f -c "%T" /var/lib/docker/overlay2输出应为xfs或ext4，非ext2），否则会额外生成 .wh. 文件加剧 inode 消耗 - 定期清理策略脚本化：每天凌晨执行
docker system prune -f --filter "until=48h"，并附加find /var/lib/docker/tmp -type f -mtime +1 -delete 2>/dev/null清理构建临时文件
长期规划：为 Docker 单独分区并调优 inode 密度
如果宿主机专用于容器运行，建议重划磁盘结构：
- 将
/var/lib/docker迁移到独立 ext4 分区，并格式化时指定mkfs.ext4 -i 4096 /dev/sdb1（每 4KB 分配一个 inode），相比默认 16KB 可提升约 4 倍 inode 总量 - 若用 XFS，创建时加
-n size=4k参数优化 inode 分配粒度，同时确保mkfs.xfs -f -n ftype=1启用 d_type 支持 - 避免与
/var/log、/tmp共享同一挂载点——这些目录的小文件洪流会加速拖垮整个分区的 inode
