关键在于用 predict_linear 做趋势预警而非静态阈值，需过滤虚拟文件系统、按业务分区设置差异化阈值，单位统一转 gb 并向上取整，配合 for、labels、annotations 和 alertmanager 抑制规则形成可操作告警。
直接用 Prometheus 监控磁盘空间，关键不是“有没有告警”，而是能不能在真正出问题前给出可操作的预警。单纯看 node_filesystem_avail_bytes 是否低于 10%，容易漏掉缓慢填满的场景，也常在日志轮转、备份完成瞬间误报。
选对指标和过滤条件
避免把 tmpfs、devtmpfs 等虚拟文件系统纳入监控——它们不占物理磁盘，却会拉低整体可用率，干扰判断。实际应聚焦真实挂载点：
- 用
node_filesystem_free_bytes{mountpoint="/", device!~"tmpfs|devtmpfs"}精准定位物理分区 - 排除容器 overlay2 或 docker 的临时挂载（如
/var/lib/docker下子路径），除非你明确要盯容器层 - 对多磁盘业务（如数据库 data 和 wal 分区），分开设置阈值，不混为一谈
用 predict_linear 做趋势预判
静态阈值只能反映“此刻是否危险”，而 predict_linear 能回答“多久后会危险”。但它不是万能外推器，必须配合适当窗口和时长：
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 历史窗口推荐
[2h]：太短（如 30 分钟）易被单次大写入带偏；太长（如 24 小时）可能混入非典型周期（周末低峰+周一高峰） - 预测时长按响应能力设：若扩容平均需 3 小时，就别用
predict_linear(..., 1*3600)—— 等告警发出来，磁盘已满 - 示例规则：
ceil(predict_linear(node_filesystem_free_bytes{mountpoint="/"}[2h], 3*3600) / 1024^3) 表示“预计 3 小时后根分区剩余不足 5GB”
单位统一与精度可控
Prometheus 所有磁盘指标单位都是字节，但人读 GB 更直观，运维 SLA 也按 GB 约定。不做转换会导致两个问题：
- 阈值写
看似简洁，实则无法区分“剩 1MB”和“已写满” - 直接比
1073741824这类数字，既难读又易错 - 务必显式转 GB 并向上取整：
ceil(... / 1024 / 1024 / 1024)，输出整数，告警内容可直接写“剩余空间低于 3GB”
配套告警机制不能少
一个裸 predict_linear 表达式只是计算，不是可用告警。必须封装成完整规则：
- 加
for: 5m避免瞬时抖动触发 - 用
labels标注业务系统、环境（如env: "prod"）、责任人（owner: "db-team"） - 在
annotations里写清建议动作：“检查 /var/log 下大日志文件”或“确认定时备份是否卡住” - 搭配 Alertmanager 的抑制规则：例如当“磁盘清理脚本已运行中”时，临时屏蔽同分区的容量告警
