Prometheus性能优化需协同指标设计、标签控制、TSDB配置和查询方式四环节：精简指标（砍冗余、维度化、降频）、扼制标签基数（禁高基数、限数量、清洗标准化）、合理设置TSDB保留策略与块参数、用记录规则替代复杂实时计算。
Prometheus 的存储与查询效率，本质上取决于指标设计、标签控制、TSDB配置和查询方式四个环节的协同。单独优化某一项效果有限，必须从数据产生源头到查询使用末端形成闭环治理。
精简指标：砍掉冗余采集，从源头减负
大量低价值指标是存储膨胀和查询变慢的首要原因。重点保留核心业务指标（如支付成功率、订单延迟）和关键基础设施指标（如节点CPU、内存、网络丢包），果断停用调试类指标（如单个pod日志行数、临时trace采样率）。
- 用 metric_relabel_configs 在采集阶段直接丢弃：例如正则匹配
node_disk_.*_bytes_total或.*_debug_.*类指标 - 避免拼接式指标名，改用标签维度化表达：把
http_requests_total_by_method_status_path拆成http_requests_total{method="GET",status="200",path="/api/order"}，减少指标总数70%以上 - 对高频但低价值指标降频采集：基础指标如
node_load1可设为60s，非关键服务指标可延长至2分钟甚至5分钟
标签优化：扼制基数爆炸，守住序列数量底线
每个新增标签值都可能引发时间序列数量指数级增长。一个含5个标签、每个标签平均有10种取值的指标，理论序列数可达10⁵=10万条——这会严重拖慢写入和查询性能。
- 禁用高基数标签：如
user_id、request_id、timestamp，改用聚合维度如user_tier（普通/VIP/企业）、region（华北/华东/华南） - 限制每指标标签数≤5个，优先保留能支撑告警、排障、容量规划的必要维度
- 用 relabel_configs 清洗标签：标准化
instance格式、删除debug_*类调试标签、合并重复环境标签（如env和environment统一为env）
TSDB 存储调优：合理设置保留策略与块参数
Prometheus 默认保留15天数据，但多数场景下30天更稳妥；同时需配合空间上限防止磁盘写满。TSDB 的块机制也影响I/O效率和查询响应。
- 按业务重要性分层保留：核心指标存90天，基础设施指标存30天，调试指标存7天，通过
--storage.tsdb.retention.time或 Helm chart 中server.retention配置 - 启用空间硬限制：如
--storage.tsdb.retention.size=10GB，避免因时间未到但磁盘已满导致服务异常 - 保持默认块时长（2h）即可，除非有特殊查询模式：短块（30m）利于近期高频查询，长块（12h）节省元数据开销，但不建议频繁调整
查询加速：用记录规则替代实时计算
复杂 PromQL（如 rate(http_requests_total[5m]) 套嵌套 sum by 或 histogram_quantile）每次执行都消耗大量CPU。记录规则将结果预计算并持久化为新指标，查询时直接读取。
- 定义常用聚合指标：如
job:http_requests_total:rate5m、cluster:cpu_usage:avg、service:latency:p95 - 设置合理的
evaluation_interval（通常15s–1m），避免过于频繁写入增加TSDB压力 - 记录规则生成的指标同样受标签和基数影响，命名和标签设计需与原始指标一致规范，不可随意添加新标签
