prometheus存储策略核心是“分层+时效”，需协同本地热存（2–7天）、归档存储（低成本长期保留）和远程写入（对接thanos等长期存储），并结合指标分级采集、预聚合与标签治理实现高效管控。
Prometheus 的存储策略核心是“分层+时效”，不是简单设个 TTL 就完事，而是结合本地热存、归档存储、远程写入三类机制协同工作。它默认不追求永久保存，而是围绕查询效率和成本做取舍——绝大多数真实查询集中在 26 小时内，所以本地 TSDB 优化的是短期高性能读写，长期留存则靠外部机制。
本地 TSDB 的 TTL 与块管理
本地存储使用时间分块（block）结构，默认每 2 小时生成一个 block，数据先写 WAL 日志，再刷入内存，满 2 小时后落盘为 block。TTL 实际由 --storage.tsdb.retention.time 参数控制，比如设为 30d，系统会在后台定期清理早于该时间的 block。
- block 会自动合并：多个小 block（如 2h）逐步合并为更大 block（如 12h、24h），减少文件数量、提升查询效率，也降低磁盘 I/O 压力
- WAL 日志只保留最近 2 小时数据，用于崩溃恢复；它不计入 retention 计算，但重启后会重放并生成新 block
- 实际保留天数可能略高于设定值——因为 block 按整块删除，不会切分小时级数据。例如设 30d，最后一批 block 可能覆盖到第 31 天凌晨
归档存储：低成本延长保留周期
归档存储不是本地 TSDB 的延伸，而是独立计费的离线存储层，专为“写一次、查极少”场景设计。它不支持实时查询，仅用于合规保留或事后回溯。
- 启用后，Prometheus 在热存期结束后（如 30 天），自动将压缩后的 block 数据同步至归档存储，再按设定天数（如 60 天）保留
- 归档单价远低于热存（例：热存 0.7 元/百万条/天 vs 归档 0.0005 元/百万条/天），适合保留原始指标全量数据
- 注意：归档数据不可直接用于 Grafana 查询，需配合远程读（remote_read）或导出工具（如 promtool）提取分析
远程写入（remote_write）：对接长期存储系统
当需要支持高并发查询、跨集群聚合或多年历史数据分析时，应绕过本地 retention 限制，把数据实时推送至专用时序数据库。
- 典型目标系统包括 Thanos、Cortex、VictoriaMetrics、InfluxDB 或云厂商托管服务（如阿里云 Prometheus 远端存储）
- remote_write 支持队列、重试、压缩（snappy）、限流，可配置 write_relabel_configs 过滤低价值指标，减少写入带宽和存储成本
- 配合 remote_read，Grafana 可无缝查询本地 + 远端数据，实现“热-温-冷”三级视图
指标生命周期的主动控制
TTL 管理不能只依赖全局 retention，更需在源头控制数据产生节奏和内容密度。
- 按业务重要性分级采集：核心链路指标用 15s，基础设施用 60s，调试指标用 300s 或关闭
- 用 metric_relabel_configs 删除无意义标签或指标，比如过滤掉
node_disk_io_now这类瞬时抖动指标 - 通过 recording rules 预聚合高频原始指标（如每秒请求量 → 每分钟 QPS），再设置独立 retention，既降存储又保分析粒度
