先止血、再抢救、最后加固：第一步暂停抓取与规则评估并缩容Pod隔离风险；第二步用ls和promtool分析WAL与blocks完整性；第三步据诊断结果选择快速恢复、跳过WAL或导出快照；第四步配置磁盘告警、WAL压缩、双维度retention及块存储PVC。
当 Prometheus 因 TSDB 本地存储空间突然耗尽而被系统强制终止（如 Kubernetes 中 OOMKilled 或进程直接退出），核心目标是：先止血、再抢救、最后加固。这不是常规备份恢复，而是紧急数据保全操作。
第一步：立即止血，阻止进一步恶化
服务已中断或反复崩溃时，首要动作不是重启，而是隔离风险源：
- 暂停所有非必要抓取任务：编辑 prometheus.yml，临时注释掉高频率或低优先级 job（如 node_exporter 的 10s 抓取），减少 WAL 写入压力
- 禁用告警与规则评估：在启动参数中加入 --rules.disable，避免 rule evaluation 占用额外内存和磁盘 IO
- 若运行在 Kubernetes 中，临时扩缩容为 0：kubectl scale deploy prometheus --replicas=0，防止新 Pod 启动失败又触发反复拉起
- 检查并清理非 TSDB 相关的临时文件（如 /tmp 下的旧快照、未压缩日志），释放几 GB 应急空间
第二步：判断数据是否可抢救
空间耗尽不等于数据损坏。关键看 WAL 和 blocks 是否完整：
- 进入数据目录（如 /var/lib/prometheus/data），执行：
ls -l wal/ && ls -l */meta.json | head -5
若 wal/ 下有大量 .seg 文件，且 blocks（如 01BKGV7JBM69T2G1BGBGM6KB12）目录存在且含完整 chunks/ 和 index，说明数据主体完好 - 运行 promtool tsdb analyze 检查块健康：
promtool tsdb analyze /var/lib/prometheus/data
重点关注 “corruption”、“invalid block”、“tombstone errors” 等关键词 - 若出现 “WAL corruption” 或多个 block 报 “invalid magic number”，则部分最近 2 小时数据可能已丢失，但历史块大概率仍可用
第三步：分场景抢救与恢复
根据诊断结果选择对应路径：
-
场景 A：WAL 完整 + blocks 可读 → 快速恢复服务
停止 Prometheus；将 data/ 整体复制到另一台有足够空间的机器（或挂载新 PV）；修改 --storage.tsdb.path 指向新路径；启动。Prometheus 会自动重放 WAL 并重建 chunks_head/，通常 1–5 分钟内恢复写入 -
场景 B：WAL 损坏但 blocks 完整 → 跳过 WAL，保留历史数据
停止服务；重命名或移走 wal/ 目录（mv wal/ wal.bak）；启动时加参数 --storage.tsdb.no-lockfile --storage.tsdb.allow-overlapping-blocks（仅限抢救）；服务可正常加载历史块，但最近 2 小时内未落盘的数据丢失 -
场景 C：磁盘已满且无法扩容 → 紧急导出可用块
用 promtool tsdb snapshot 导出指定时间范围的块：
promtool tsdb snapshot --skip-create --snapshot-dir /tmp/snap-$(date +%s) /var/lib/prometheus/data 2026-05-20T00:00:00Z 2026-05-22T00:00:00Z
生成的快照是独立目录，可立即 tar 压缩后转移，后续用 tsdb convert 导入其他环境
第四步：事后加固，避免复发
抢救只是临时手段，必须同步落地防御措施：
- 设置硬性磁盘水位告警：监控 node_filesystem_avail_bytes{mountpoint="/var/lib/prometheus"}，在剩余 <15% 时触发通知
- 启用 WAL 压缩（2.20+ 默认开启）：确认配置含 --storage.tsdb.wal-compression，可减少 40%+ WAL 占用
- 调整 retention 策略：避免盲目设为 “10000d”。按实际需要设定，例如：
--storage.tsdb.retention.time=720h（30天）+ --storage.tsdb.retention.size=100GB（双保险） - 对 K8s 环境，PVC 必须使用 block storage（如 AWS EBS、Ceph RBD），严禁 NFS/EFS —— 官方明确警告其会导致 TSDB 元数据损坏
