先把当时的情况摆出来。日志盘以每小时 8G 的速度增长，Prometheus 里明明有 node_filesystem_avail_bytes，可直到写满触发服务异常才有人发现，中间没有任何预警。
原因不止一个，得分开看。告警规则只配了使用率超过 90% 的阈值，涨得快时来不及反应。也可能是predict_linear 用的时间窗口太短，数据抖动导致预测值失真。
另外，告警规则的 for 设成 30 分钟，磁盘早在这之前就满了。少数情况下是告警发到了没人看的邮件组，值班同学没收到。
先确认指标和预测值是否正常
curl -s 'http://127.0.0.1:9090/api/v1/query?query=node_filesystem_avail_bytes' | head -c 400接着用 predict_linear 算四小时后的余量
curl -sG 'http://127.0.0.1:9090/api/v1/query' --data-urlencode 'query=predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[1h], 4*3600)'然后把预测规则写进告警文件并热加载
promtool check rules /etc/prometheus/rules/disk.yml && curl -X POST http://127.0.0.1:9090/-/reload触发一次测试告警确认链路通畅
amtool alert add DiskWillFillIn4Hours severity=warning --alertmanager.url=http://127.0.0.1:9093恢复的判定其实很直接。Prometheus 的 rules 页面能看到新规则处于 firing 或 inactive 的正常状态，测试告警在 1 分钟内送达值班群，磁盘增长时提前四小时收到通知。
容易忽略的是，预测类告警要和阈值告警配合用，单靠使用率永远慢一步；窗口至少取一小时，太短会被日志轮转造成的回落带偏。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。