真正有效的磁盘增长感知需结合变化率监控、写入事件监听与多维指标闭环：用inotifywait捕获实时写入，限定关键路径，分层阈值预警Use%与Inodes，同步检查已删未释放文件，并通过历史采样估算增速与满盘时间。
df 命令只能看瞬时快照，不能反映增长趋势
直接跑 df -h 只能告诉你“此刻用了多少”，但业务磁盘每天涨 2GB 还是每小时涨 500MB，它完全不体现。真实运维中，告警总在爆满前 1 小时才触发，说明你缺的是**变化率**，不是静态值。
- 单纯定时
df轮询（比如每 5 分钟一次）会产生大量冗余数据，且无法区分正常写入和异常暴增 - 用
du扫目录虽能定位热点，但耗时长、IO 高，不适合高频监控 - 关键路径必须限定：优先监控
/var/log、/var/lib/docker/overlay2、/data、/tmp，其他挂载点可降频或忽略
用 inotifywait 捕获实时写入事件，比轮询更准
真正有效的增长感知，得靠监听文件系统事件——谁在写、写了什么、频率多高。这比等 df 报警早至少 10～30 分钟。
- 命令示例：
inotifywait -m -e create,modify,attrib /var/log --format '%w%f %e' | awk '{print $1}' | awk '{count[$1]++} NR%60==0 {for(i in count) if(count[i] > 50) print "ALERT: " i " written " count[i] " times in last minute"; delete count}' - 注意权限：若监控
/var/log下 www-data 写的日志，需用sudo -u www-data inotifywait ...，否则收不到事件 - 避免递归：加
-r会卡死，尤其在/var/lib/docker/overlay2这种深层结构下，只监顶层目录即可
预警日志要分层阈值 + 排除 root 保留空间干扰
df 显示的 Avail 是扣掉 root 保留空间（默认 5%）后的值，但 nginx、dockerd 等服务以 root 身份运行，实际还能多用约 5%。硬写 if [ $(df / | awk 'NR==2 {print }' | sed 's/%//') -gt 90 ] 会误报。
- 正确做法：取
Use%值后做滑动窗口判断，例如连续 3 次 ≥85% 才触发一级预警，≥92% 触发二级 - 必须同步检查 inode：
df -i /，尤其在日志归档、容器镜像场景下，Use%才 60% 但Inodes已 98%，照样报No space left on device - 已删未释放文件也要纳入预警逻辑：
lsof +L1 | wc -l> 10 就该告警——这类文件常占数 GB 且不显现在du结果里
增长趋势靠历史采样 + 简单拟合，不用上 Prometheus
生产环境真没必要为磁盘趋势单独搭一套监控栈。用 shell 记录 + awk 做线性估算，够用且可控。
- 每 10 分钟执行：
echo "$(date +%s) $(df / | awk 'NR==2 {print $3}')">/var/log/disk_usage.log - 查最近 24 小时增速：
awk '$1 > systime()-86400 {sum+=$2; n++} END {print sum/n}' /var/log/disk_usage.log，单位是 KB/秒 - 预测满盘时间：
awk '$1 > systime()-3600 {a[NR]=$2} END {k=(a[NR]-a[1])/(NR-1); print int((a[NR]+(100-a[NR]/$(df / | awk 'NR==2 {print $2}')*100)*$(df / | awk 'NR==2 {print $2}')/100)/k/3600) "h"}' /var/log/disk_usage.log（需替换内嵌命令）
真正容易被忽略的不是命令怎么写，而是没把 df -i、lsof +L1 和写入事件监听三者串成闭环——任缺一环，都会在凌晨三点收到“磁盘已满”的电话。
