限制指标采集频率需按需分级、精准控制并配合过滤：关键业务指标10–15秒，基础设施指标30–60秒，低频指标2–5分钟或按需采集；各job独立配置scrape_interval与scrape_timeout；通过metric_relabel_configs白名单过滤高基数指标；优化后需验证scrape耗时、失败率及时间序列数是否稳定。
限制指标采集频率不是简单调大间隔，而是按需分级、精准控制、配合过滤的组合动作。核心目标是降低 Prometheus 自身负载和存储压力，同时不丢失关键观测能力。
按业务重要性分级设置 scrape_interval
统一用 15 秒抓取所有指标最容易导致过载。应根据指标变化节奏和业务影响程度分档配置：
- 支付成功率、订单量等关键业务指标：设为 10–15 秒，确保异常能被快速捕获
- CPU、内存、磁盘 IO 等基础设施指标：设为 30–60 秒，系统级指标本身波动平缓，过密采集反而引入噪声
- JVM GC 次数、日志行数、配置变更事件等低频指标：设为 2–5 分钟，或通过 on-demand 方式触发采集
在 job 级别单独配置，避免全局一刀切
不要只依赖 global scrape_interval。每个采集任务应独立定义节奏，并同步调整超时时间：
- 在
scrape_configs中为每个 job 显式声明scrape_interval，例如：- job_name: 'payment-api'<br> scrape_interval: 15s
- job_name: 'backend-worker'<br> scrape_interval: 60s
- 配套设置
scrape_timeout，建议为scrape_interval的 2/3（如 interval=60s，则 timeout≤40s），防止超时阻塞下一轮抓取
用 metric_relabel_configs 过滤低价值指标
光调间隔不够——如果每次仍拉回成百上千个带高基数标签的调试指标，压力依然很大。必须结合白名单过滤：
- 在 job 配置中添加
metric_relabel_configs，只保留真正需要的指标名，例如只保留http_requests_total、process_cpu_seconds_total - 丢弃带大量动态标签的指标（如含
request_id、user_id的计数器），这类指标极易引发时间序列爆炸 - 对 Histogram 类型指标尤其谨慎：若无需 P90/P99 计算，改用 Gauge 记录原始值，在 PromQL 中聚合更轻量
验证优化是否生效
调完不能就不管了，要靠内置指标确认效果：
- 查
scrape_duration_seconds：看各 job 平均抓取耗时是否下降 - 看
prometheus_target_scrapes_failed_total：失败率是否明显降低 - 观察
prometheus_tsdb_head_series：活跃时间序列数是否趋于稳定，避免持续增长
