磁盘空间告警阈值没有放之四海而皆准的固定数值，它是基于分区容量、数据增长速率和业务容忍度算出来的动态值，而不是拍脑袋定下的静态百分比。
设置过高的阈值,比如等磁盘用满再告警，系统可能已经卡死，运维连登录上去清理的余地都没有，设置过低的阈值，比如刚用 30% 就告警，告警风暴会直接淹没真正需要处理的故障，一个健康的告警策略，应该能提前预测到磁盘写满的时间点，而不是等它写到满才提醒你。
磁盘告警阈值设置多少合适？先看这三个数据点
很多刚入行的运维习惯在监控系统里把磁盘使用率阈值固定设成 80% 或 90%，这种做法在分区足够大的时候勉强能用，一旦遇到日志量突增或备份任务集中的时段，就很容易被打个措手不及，业内专家指出，合理的阈值设定应该围绕以下三个变量展开。
分区总容量是阈值计算的地基
1TB 的数据盘用到 80% 还剩 200GB，能撑很久，但 40GB 的根分区用到 80% 只剩 8GB，可能一场编译任务或者一个 Docker 镜像拉取就写满了。容量越小的分区，阈值百分比必须设置得越低，留出足够的绝对空闲空间。
反过来,超大容量的存储卷，比如几十 TB 的备份盘，哪怕使用率到了 95%，如果每天只有几十 GB 的增量，也还能撑好几个星期，这时候单纯看百分比告警就没意义了，得看剩余绝对空间。
数据增长速率决定了告警的提前量
磁盘告警的核心目的不是告诉你“现在满了”，而是告诉你“按当前速度，再过多久会满”，系统日志、业务数据库、用户上传文件，这三类数据的增长速度完全不是一个量级。
- 日志型分区：高峰流量时段增长极快，建议按小时预测。
- 数据库分区：增长相对平稳，可以按天或按周预测。
- 备份与归档分区：集中在凌晨跑批，需要区分增量备份日与全量备份日。
如果要多写一步,建议设置一个单独的“磁盘增长速率监控”，计算当前使用率的变化斜率，比如过去 24 小时从 70% 涨到了 90%，就算当前没有超过阈值，也说明有异常在疯狂写盘，需要马上查。
业务可容忍的“最长无干预时间”
这里指的是从收到告警到磁盘写满,中间留给运维操作的窗口期，如果业务要求高可用，比如在线交易系统，磁盘写满一秒都是事故，那阈值就得让人工介入时还有
至少 24 小时的缓冲。
如果是一般性的内部测试环境,或者大批量数据导入后就能清理的临时目录，可以适当放宽，这个变量直接决定了告警的最终触发线。
不同分区类型，磁盘空间告警阈值参考思路
服务器上每个分区承担的角色不一样,对磁盘告警阈值设置的参考思路也不能一刀切，Linux 系统里常见的分区角色大致有这几类，各自的看护重点完全不同。
根分区与系统盘：推荐 80% 猫腻最少
根分区装系统、装软件，还要处理临时文件和内核日志，很多软件安装时对 /tmp 空间有强制要求，比如解压大安装包时空间不足会导致安装直接失败。系统盘建议使用率超过 80% 就触发警告级告警，超过 90% 触发紧急级告警，原因是根分区一旦写满，出的不只是磁盘告警，还伴随各种服务无法创建临时文件导致的连锁故障。
再补充一点,/var 目录下的日志默认使用率也要单独盯着，logrotate 如果配置不周，系统日志可以悄无声息地吃满整个分区，尤其在跑着 Nginx、MySQL 或 Java 应用的服务器上。
数据盘与业务存储：别只看百分比了
挂载在 /data 或 /home 下的数据盘是业务的主战场，写满了业务直接挂掉，这里的阈值要结合文件大小特征设置。大数据量小文件场景，比如图片服务，建议剩余空间超过 50GB 就进入预警；大文件顺序写入场景，比如视频转码，可以设置剩余空间超过 100GB 预警。
尽量用绝对空间值做硬指标
数据盘空间大,使用率从 93% 到 95% 看起来只涨了 2%，但实际占用却可能是几十 GB，建议针对数据盘增加一个绝对剩余空间的告警条件，剩余空间低于 50GB”或者“剩余 inode 低于 10 万”，作为百分比阈值之外的辅助判断。
日志分区与临时目录：按小时维度盯防
日志分区是最常出幺蛾子的地方,应用打印堆栈、访问日志、慢查询日志，在流量高峰时一小时生成几十 GB 都正常，这里建议把告警阈值设置得很保守，日志分区使用率超过 70% 就需要人工看一眼，并配置一个“单日日志增量超过 20GB”的独立告警。
生产上见过多次因为调试日志没关,一晚上把 200GB 磁盘写满的案例，这类报错虽然不频繁，但每次出现都极其被动。
告警级别怎么分层？从预警到紧急的阶梯式响应
告警阈值不是单一的一个数,而是阶梯式的一组条件，行业共识认为，完整的磁盘空间告警至少要有三个级别，分别对应不同的处理流程。
预警级：解决“要不要现在看”
触发条件：磁盘使用率超过容量参考值的 75%，或预计剩余使用时间少于 7 天，处理方式：通知群发消息，由运维记录后当日观察，不一定要立刻处理。
警告级：解决“今天必须处理”
触发条件：使用率超过 85%，或预计剩余使用时间少于 48 小时，处理方式：触发页面告警，需要登录服务器定位占用大头，清理已完成的历史日志、过期备份包或临时文件。
紧急级：解决“现在立刻处理”
触发条件：使用率超过 92%，或剩余空间低于预先设定的绝对值（10GB 或 5%），处理方式：电话通知与短信通知，必须配合自动清理脚本，比如自动执行 journalctl --vacuum-time=2d 或清空 /tmp 下超过 3 天未访问的临时文件。
如果这个等级没有自动化的兜底动作,那告警配置实际上是不完整的，因为人不可能永远在几秒内就跑到电脑前操作。
磁盘空间告警脚本怎么写的实操注意事项
理论说了不少,落到监控工具的配置上，需要关注几个高频踩坑点，以最常见的 Linux 环境下使用 cron 或 systemd timer 定时跑脚本为例，需要注意脚本本身的健壮性。
如果你的告警脚本挂在了监控系统里
在 Zabbix 或其他监控平台中设置触发器时，务必加上数据变化函数，比如检测 vfs.fs.size[/,pused] 大于 85 是基础写法，但更好的做法是加入 last() 和 timeleft() 组合来判断趋势，否则云主机磁盘空间管理和临时扩容引起的波动很容易造成误报。
避免采集命令本身的性能开销
许多运维用 df -h 做告警数据源，但这个命令在磁盘挂载点数量较多或某些网络文件系统（NFS）卡顿的情况下，执行时间会很长，甚至导致脚本挂起，建议直接读取 /proc/mounts 和 statvfs，或者使用 df 时加上 --local 参数只检查本地磁盘。
告警信息必须带上时间戳和分区名
模糊的告警（磁盘满”）与精确的告警（2024-06-18 14:30，/data 分区告警，总容量 2TB，已使用 1.85TB，剩余 150GB，按当前速率预计 36 小时后写满”）对处理故障的效率影响差异巨大，少写一行提取分区信息的代码，后续排查会多花十倍时间。
| 分区类型 | 推荐预警阈值 | 推荐紧急阈值 | 辅助指标 |
|---|---|---|---|
| 根分区 | 80% | 90% | 剩余 inode 数 |
| 数据盘 | 85% | 92% 或剩余不足 50GB | 增长速率（MB/小时） |
| 日志分区 | 70% | 85% | 单日日志增量 |
| 备份盘 | 90% | 95% | 最近一次备份是否成功 |
磁盘空间告警阈值设置常见问题
磁盘使用率没到阈值，但服务已经因为磁盘报错了，怎么回事？
可能是 inode 用尽了，数据块还有剩余空间，但文件索引节点耗尽，导致无法创建新文件，建议在监控项里加入 df -i 的检查，将 inode 使用率告警阈值设为 90% 与空间使用率分开配置。
云服务器磁盘怎么设置告警？使用率长期 60% 左右，还有必要提升阈值吗？
需要结合云盘的计费逻辑来看,如果系统盘是 40GB，数据盘是 100GB，使用率即使只有 60%，剩余空间也仅 40GB 左右，在云环境下，主要看数据盘吞吐需求是否要求扩容到更高规格，如果业务增长快，建议直接扩容而不是提高告警阈值，因为靠调高阈值来掩盖容量规划不足，早晚要出问题。
设置了 75% 的告警阈值之后，总是半夜收到日志分区的告警，但白天看容量是够的，怎么回事？
日志分区会周期性回滚,logrotate 每天压缩切割日志，压缩前瞬间占用大，或备份任务在凌晨全量写入，这种情况建议对监控项使用按小时统计的聚合函数，或者把告警动作设定为“持续触发 15 分钟以上才发送”，这样既能过滤瞬时波动，又不至于漏掉持续写入的故障，磁盘监控落到细处，就是规避误报、及时响应、留足余量这十二个字，用动态预测替代静态百分比，你的磁盘告警才真正能成为事故预警信号，而不是事故发生后的一声马后炮。