排查磁盘满载风险需从指标趋势、数据构成和存储行为三层面提前识别：用PromQL计算空间消耗速率与耗尽时间，定位Prometheus数据膨胀源头（TSDB块、WAL、chunks_head），核对保留策略与采集频率，并通过inode、磁盘写入量等指标揪出异常进程。
排查磁盘满载风险，关键不是等告警响了再救火，而是从指标趋势、数据构成和存储行为三个层面提前识别压力苗头。Prometheus本身不直接“监控磁盘”，但它采集的指标能精准反映磁盘空间的消耗节奏与异常征兆。
看趋势：用PromQL识别空间耗尽倒计时
单纯看当前使用率（如 100 - (node_filesystem_avail_bytes / node_filesystem_size_bytes * 100)）容易误判——85%可能很安全，92%却可能只剩2小时。真正有用的是预测性指标：
- 计算每日增长速率：
rate(node_filesystem_avail_bytes{mountpoint="/"}[24h])，负值越小（绝对值越大），说明每天被吃掉的空间越多 - 估算耗尽时间（单位：小时）：
(node_filesystem_avail_bytes{mountpoint="/"}) / (rate(node_filesystem_avail_bytes{mountpoint="/"}[6h]) * 3600)，结果小于24就该介入 - 对比多个挂载点增速，比如
/var/lib/prometheus/data增速远高于/整体，基本锁定是TSDB写入失控
查构成：定位Prometheus自身数据膨胀源头
Prometheus自己的数据目录（通常是 /prometheus/data/）占满，比系统其他目录更危险——它会让整个监控停摆。重点检查三类子目录：
-
TSDB块目录（如
01Jxxxxx）：每个目录代表一个2小时压缩块，数量多且单个大，说明保留时间过长或采样太密 -
WAL目录（
wal/）：正常应＜1GB；若持续＞5GB，大概率是Prometheus反复崩溃重启，WAL没来得及压缩归档 - chunks_head：通常较小；异常增大说明内存中未刷盘数据积压，常伴随高负载或写入阻塞
验配置：确认保留策略与采集频率是否匹配
很多爆盘问题源于“默认配置+放任生长”。必须核对两项硬性设置：
- --storage.tsdb.retention.time：默认是15d，若指标量大（如每秒采集上千target），建议缩至3–7天，并配合定期清理
- scrape_interval 和 scrape_timeout：对非核心服务，把采集间隔从15s拉长到60s或2m，可降低3–4倍存储压力
- 检查是否有冗余target，比如同一台机器被Node Exporter、Process Exporter、Custom Exporter重复采集，标签组合爆炸式增长
盯异常：识别非存储类但加速满盘的行为
有些进程不写Prometheus数据，却会快速拖垮磁盘，而Prometheus指标能最早暴露线索：
-
node_filesystem_files_free跌破阈值：inode耗尽比空间耗尽更隐蔽，会导致新建文件失败，Prometheus WAL写入卡住 -
rate(node_disk_written_bytes_total[1h])突增：结合进程指标process_open_fds或日志路径写入量，快速定位日志狂吐、备份任务卡死等真凶 -
node_filesystem_readonly== 1：只读挂载常是内核触发保护机制的结果，根源仍是空间或inode不足
