报错是这么冒出来的。Prometheus 2.40 在 CentOS 7 上跑，unit 的 ExecStart 里写了 –storage.tsdb.retention.time=30d，但 Grafana 查二十天前的曲线全是断点，数据目录只有 40G，盘还剩三百多 G。
原因不止一个，得分开看。drop-in 里还留着旧的 –storage.tsdb.retention=15d，后出现的参数覆盖了前面的。也可能是改完 unit 没 daemon-reload，进程还是用旧参数重启的。
不容易想到的是，写参数时带了引号，systemd 把它当成一个整体传进去，Prometheus 解析失败回退默认值。
第一件事是查进程实际生效的参数
curl -s localhost:9090/api/v1/status/flags | jq -r '.data["storage.tsdb.retention.time"]'再往下找出重复定义的位置
grep -rn retention /etc/systemd/system/prometheus*随后统一到一处并重载
systemctl daemon-reload && systemctl restart prometheus剩下的就是确认数据目录余量
du -sh /var/lib/prometheus/data; df -h /var/lib/prometheus手上没有现成的复现脚本，就照着线上请求手工拼了一个。
别只看报错消失，验证要多做一步。status/flags 返回 30d，status/tsdb 里最老 block 的 maxTime 超过二十天，Grafana 拉二十天前的曲线连续无断点。
补一句。Prometheus 删数据是按 block 整块删，调整后要等新 block 生成才看得出效果；磁盘不够时它会先保最近数据，别把容量问题误判成参数问题。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。