磁盘空间告警阈值没有万能数值，建议按“容量分段+增长速率+业务容忍度”三层动态设定，而不是简单写个百分比。
磁盘空间告警阈值设置多少合适？先看容量再看增速
很多运维新手喜欢给所有磁盘设同一个告警阈值,比如统一80%报警，这个思路在混合环境里很容易翻车，一块20GB的系统盘和一块2TB的数据盘，同样达到80%，前者可能半天就写满，后者还能撑几周，行业共识认为，阈值必须跟随磁盘容量和增长速率动态调整。
小容量磁盘阈值要高，大容量磁盘阈值要低
为什么反直觉？小磁盘可用空间绝对值小，百分比变化快，比如40GB的根分区，85%时只剩6GB，可能一夜间被日志塞满，这时候阈值设在85%反而太晚，应该更早预警，但太早又会导致告警频繁，实践中的折中方案是：
- 低于100GB的磁盘：告警阈值设置在75%-80%，紧急阈值90%
- 100GB到1TB的磁盘：告警阈值设置在85%，紧急阈值92%
- 超过1TB的磁盘：告警阈值设置在90%，紧急阈值95%
这只是一个参考区间,真正的关键不是数字本身，而是“剩余空间还能撑多久”。
用增长速率倒推触发时间
与其死盯着百分比,不如看趋势，假设磁盘每天增长2%，当前使用率是78%，那么达到85%需要大约3.5天，如果把阈值设为80%，留出2.5天的处理时间，就合理得多，操作上，可以采集最近7天的使用率数据，计算平均日增量，然后按“预计剩余天数”来设置。
具体方法：
- 记录每天同一时刻的磁盘使用率（比如凌晨2点）
- 计算连续两天的差值,取平均值
- 用（告警阈值 – 当前使用率）÷ 日均增量，得到预计可用天数
- 如果预计天数小于等于3天,就触发告警
这个逻辑比固定百分比更贴近现实,很多监控系统，比如Prometheus和Zabbix，都能基于历史数据做预测，如果你用的是简单脚本，也可以手动加一层趋势判断。
不同业务场景的容忍度差异
数据库服务器的数据盘和Web服务器的日志盘,容忍度完全不同，数据库磁盘写满是灾难，可能直接导致实例崩溃；日志盘写满最多丢一些日志，服务还能扛一阵。
- 数据库、存储目录：阈值要低，比如70%就要通知，80%紧急处理
- 应用日志、临时文件目录：阈值可高一些，85%通知，92%清理
- 备份、归档盘：阈值看写入计划，通常在80%处设置一个“提醒级”即可
另一个场景是云服务器,云盘扩容方便，但并非所有环境都支持热扩容，如果云盘不支持在线扩容，阈值就必须留出人工操作时间，这种情况下，告警阈值也要考虑“扩容流程耗时”，比如需要1天审批，那阈值就要保证至少能撑2天。
linux磁盘空间告警阈值设置实操
Linux环境下的磁盘告警,最常用的是df命令配合脚本或监控工具，手动查看时，可以用df -h，但脚本里建议用df -P，避免行被截断。
df与du的配合用法
df显示文件系统整体使用率，du统计目录实际占用，告警触发后，先用df -h确认是哪个挂载点满了，再用du -sh /逐层找大目录，这里有个坑：如果文件被删除但进程仍持有句柄，df显示已用空间不会下降，排查时需要执行lsof +L1找出已删除但未释放的文件，然后重启对应进程或服务。
用cron脚本设置阈值
一个简单可靠的方案是写Shell脚本,加入crontab，脚本思路如下：
- 定义阈值变量,比如
WARN=85，CRIT=95 - 用
df -P | awk解析每行使用率 - 当使用率超过
WARN时，输出日志或调用webhook；超过CRIT时，发送短信通知 - 排除特殊文件系统,如
tmpfs、overlay、udev
建议脚本中不要写死磁盘列表，而是用正则匹配真实分区，比如排除以外的伪文件系统，注意df输出里的/dev/sda1才是实体盘。
日志轮转与清理联动
阈值告警不能只报警不处理,业界常用的做法是把告警触发和日志清理动作联动。
- 每天凌晨执行
logrotate，按大小轮转日志，保留最近7份 - 当磁盘使用率超过90%时，强制清理
/var/log下超过7天的.gz压缩包 - 对Tomcat、Nginx等应用日志，定义
find /data/logs -mtime +3 -delete的定时任务
这套组合能极大降低人工介入频率,但要小心清理范围，别把数据库binlog或审计日志误删。
zabbix磁盘空间告警阈值设置参考
Zabbix是自建监控里常见的选择,它的磁盘空间监控依赖agent采集，默认监控项是vfs.fs.size[]，设置阈值时，很多人直接在触发器里填固定百分比，这会导致前面说的容量适配问题，更好的方式是基于last()函数配合趋势函数。
zabbix监控项与触发器
- 监控项：
vfs.fs.size[fs=<挂载点>,<mode>]，mode选pused即可 - 触发器表达式示例：
last(/主机/监控项)>85 - 要加入持续时间判断,比如
last(/host/vfs.fs.size[fs=/data,pused])>85 and last(/host/vfs.fs.size[fs=/data,pused])持续十分钟
如果不加持续时间,磁盘使用率每次短暂超过阈值都会告警，造成疲劳轰炸，建议所有磁盘告警触发器都加上min(10m)的时间窗口。
避免误报的“持续时间”技巧
Zabbix触发器支持time函数。
last(/node1/vfs.fs.size[fs=/,pused])>85 and last(/node1/vfs.fs.size[fs=/,pused]) < 90
这表示85%-90%区间，持续10分钟才触发，如果直接到90%以上，可以立即触发严重级别，这种分级设计能减少无意义告警，同时保证严重问题不被延迟。
对于动态根目录,比如容器宿主机，的使用率可能被镜像层撑大，建议同时监控/var/lib/docker目录在du层面的实际占用，Zabbix里可以用system.run[du -s --block-size=1G /var/lib/docker]配合自定义脚本，但要注意agent的权限配置。
Windows磁盘空间告警阈值设置
Windows环境没有df命令，但可以通过PowerShell脚本或性能计数器实现类似效果，多数Windows服务器磁盘是C盘系统盘加D盘数据盘，考虑与Linux相同的容量分段逻辑。
使用性能计数器
Windows自带的逻辑磁盘性能计数器里,LogicalDisk对象的% Free Space可以用来监控，在性能监视器里添加警报，当可用空间低于设定值时触发事件，不过这种方式配置较繁琐，而且默认计数器反映的是全部磁盘实例，容易混淆。
更直观的方法是写PowerShell脚本,结合任务计划程序：
- 用
Get-Volume获取磁盘剩余空间和容量，计算使用率 - 设定阈值参数,比如
$warn=85 - 超过阈值时,触发弹窗、日志或发送邮件
- 任务计划里设置每5分钟运行一次
脚本中要注意排除系统保留分区和恢复分区，只监控有盘符的卷，对于云服务器Windows镜像，有些还有Z盘等隐藏分区，需要靠DriveType过滤。
图形化工具和第三方方案
不排斥命令行的话,可以用fsutil file createnew快速生成测试文件来验证清理策略，对于小团队，Windows自带的“存储感知”功能也能自动清理临时文件，但这些功能默认不发送网络告警，生产环境建议结合商业监控或自定义脚本。
磁盘空间告警阈值设置的常见误区
只设百分比，不看绝对空间
同一个90%，在10GB分区上是1GB剩余，在10TB分区上是1TB剩余，前者可能半小时就没了。百分比必须换算成绝对剩余空间，再结合写入速度判断，经验做法是，在监控视图里同时展示“已用百分比”和“剩余绝对值”，阈值判断用百分比，人工处理时先看剩余绝对值。
阈值一成不变
业务扩容、日志量变化、磁盘容量扩增后，原有阈值可能不再适用，比如磁盘从500GB扩到2TB，如果还沿用90%告警，剩余空间从50GB变成200GB，告警失去了紧迫性，建议每次变更后重新评估增长速率和告警阈值，统计表明，固定阈值的误报率会随环境变更显著上升。
忽略inode耗尽
Linux下磁盘使用率没满,但文件系统inode耗尽，同样无法写入。df -i可以查看inode使用率，建议把inode告警与空间告警分开设置，阈值通常设为管理员希望提前清理小文件的程度，比如inode使用率超过80%就预警，因为小文件只能手工清理，耗时更长。
磁盘空间告警阈值常见问题解答
问：磁盘空间告警阈值设置多少合适？有标准答案吗？
没有统一标准,但行业共识是：根据磁盘容量和业务重要性动态调整，小容量磁盘用75%-80%告警，大容量磁盘用90%告警，数据库目录和系统盘从紧，日志和备份区从宽，最可靠的做法是结合日均增长量，计算达到阈值所需天数，把告警提前到“还有3天以上”的节点。
问：Zabbix和Prometheus谁更适合做磁盘空间告警？
两者各有侧重,Zabbix自带vfs.fs.size监控项和触发器，配置路径直观，适合传统服务器监控，Prometheus配合node_exporter，node_filesystem_avail指标更灵活，适合容器和云原生环境，选择时主要看现有技术栈如果团队熟悉Zabbix，没必要为了磁盘告警单独引入Prometheus。
问：磁盘空间告警触发后，第一步应该做什么？
先确认是空间真实占用高,还是文件未释放，执行lsof +L1（Linux）或重启持句柄进程；若占用属实，按du从根目录逐层定位大文件，优先清理日志、临时文件、旧备份，处理完务必检查增长速率，判断是否需要调整当前阈值。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/773920.html
