prometheus 通过 wal 压缩、tsdb 块合并及源头精简数据实现高效存储优化；启用 --storage.tsdb.wal-compression 可减小 wal 体积 30%–50%，默认 2.20+ 开启；合理配置保留策略（时间与空间双限制）并配合 metric_relabel_configs 降维去冗，显著降低存储压力。
Prometheus 本身不提供传统意义上的“数据去重”功能，但通过内置的 TSDB 压缩机制、WAL 压缩、块合并与合理配置，能显著减小存储压力。关键不是后期压缩，而是让数据从写入开始就更紧凑、更少、更结构化。
启用 WAL 压缩，降低写入开销
Prometheus 的 Write-Ahead Log（WAL）用于保障崩溃恢复，但原始 WAL 文件体积大、I/O 高。启用压缩后，WAL 占用可减少 30%–50%，且对 CPU 影响极小。
- 命令行参数：
--storage.tsdb.wal-compression - Helm 配置示例：
server.extraFlags: ["--storage.tsdb.wal-compression"] - 注意：Prometheus 2.20+ 默认启用，旧版本需显式开启
优化块压缩与合并策略
TSDB 将数据按时间切分为“块”（默认每 2 小时一个），后台自动压缩小块为大块。压缩效果取决于数据特征和块生命周期，无需手动干预，但需确保配置合理：
- 保持默认
--storage.tsdb.min-block-duration=2h即可，频繁调整反而影响稳定性 - 最大块大小受保留时间限制（通常 ≤ 31 天或保留期的 10%），无需额外设置
- 定期检查
prometheus_tsdb_head_chunks_created_total和prometheus_tsdb_compaction_duration_seconds，确认压缩任务正常运行
从源头减少待压缩数据量
压缩再强，也难救海量低价值序列。真正有效的“压缩”，是让进来的数据更精简：
- 用
metric_relabel_configs在采集时丢弃冗余指标，如node_disk_.*、.*_debug_.* - 避免拼接式指标名，改用标签表达维度，例如把
http_requests_by_method_status拆成http_requests_total{method="POST",status="500"}，减少指标总数 70%+ - 高频低价值指标降频采集（如非核心服务指标设为 120s 或 300s），直接减少样本生成速率
配合保留策略与空间限制
压缩不能替代清理。必须设定明确的“边界”，防止磁盘耗尽导致 WAL 写失败或 TSDB 崩溃：
- 时间保留：
--storage.tsdb.retention.time=30d（核心指标可延长至 90d） - 空间硬限制：
--storage.tsdb.retention.size=10GB，建议设为磁盘总容量的 80%–85% - 二者可共存，任一条件满足即触发清理，推荐同时启用
