Prometheus性能调优需按业务重要性分级设置抓取间隔：关键业务指标10–15秒、基础设施指标30–60秒、低频指标2–5分钟；在job级别精细配置scrape_interval与timeout；通过metric_relabel_configs白名单过滤指标；配合分级存储策略与块压缩优化成本与性能。
抓取频率和存储成本是 Prometheus 性能调优中最直接、最见效的两个杠杆。调得过密，资源吃紧、查询变慢、磁盘告急；调得过松，又可能错过关键波动或告警延迟。核心不是“统一设成多少”，而是“按需分级、精准控制、持续验证”。
按业务重要性分档设置抓取间隔
不同指标对实时性的敏感度差异很大，一刀切的 15 秒采集既不经济也不合理：
- 关键业务指标（如支付成功率、API 错误率、下单量）：建议设为 10–15 秒。这类指标异常往往意味着营收损失或用户流失，需要快速感知突变。
- 基础设施指标（如 CPU 使用率、内存占用、网络收发字节数）：推荐 30–60 秒。系统级指标本身变化平缓，高频采集不仅冗余，还容易把瞬时毛刺当问题。
- 低频或调试类指标（如 JVM GC 次数、日志行数、配置变更事件）：可放宽至 2–5 分钟，甚至通过 webhook 或 on-demand 方式触发采集，避免持续占用抓取带宽。
在 job 级别精细控制，避免全局配置失灵
global scrape_interval 只是兜底值，真正起作用的是每个 job 的独立配置。这样既能统一基线，又能灵活适配不同服务的节奏：
- 在
prometheus.yml的scrape_configs中为每个 job 显式声明scrape_interval，例如：- job_name: 'order-service'<br> scrape_interval: 15s
- job_name: 'cache-worker'<br> scrape_interval: 60s
- job_name: 'log-collector'<br> scrape_interval: 300s
- 同步调整
scrape_timeout，一般设为scrape_interval的 2/3（如 interval=60s，则 timeout=40s），防止超时中断影响下一轮抓取。
用 metric_relabel_configs 过滤无效指标，从源头减负
光调间隔不够——如果每次仍拉回成百上千个无用指标（比如带大量 label 的调试计数器），存储和查询压力依然居高不下：
- 在 job 配置中加入
metric_relabel_configs，优先用keep白名单保留真正用于告警或分析的指标名，例如：- source_labels: [__name__]<br> regex: "http_requests_total|node_cpu_seconds_total|go_memstats_heap_alloc_bytes"<br> action: keep
- 避免大面积
drop，逻辑难维护且易误删；过滤发生在采集后、写入前，虽不减少网络传输量，但能显著降低 TSDB 存储体积与 PromQL 查询开销。
配合存储策略，让数据“该留的留，该走的走”
抓取降下来了，但历史数据若长期堆积，磁盘照样爆满。需同步收紧保留策略：
- 将默认的
--storage.tsdb.retention.time=15d按场景缩短：核心业务指标保留 7–15 天，基础设施类可压到 3–7 天，调试类建议 1–2 天。 - 对长期归档需求，不要硬扛——接入 Thanos 或 Cortex，把老数据下沉到对象存储（如 S3），本地只留热数据，兼顾查询性能与成本。
- 确认块压缩正常运行（默认每 2 小时一个 block），避免因频繁 compact 导致 I/O 峰值；SSD 存储介质仍是提升写入吞吐的性价比首选。
