4. 指标采集优化：Scrape Interval、Scrape Timeout、Sample Limit 的合理配置策略
指标采集是 Prometheus 生态中最基础也最关键的环节。Scrape Interval（采集间隔）、Scrape Timeout（采集超时）和 Sample Limit（样本数限制）三个参数直接决定了采集系统的稳定性、资源消耗和数据完整性。本章从工程实践角度，给出这三者的配置策略与调优方法。
4.1 三个核心参数的定义与关系
在 Prometheus 的 scrape_config 中，这三个参数共同作用于每一次采集任务：
| 参数 | 默认值 | 作用域 | 核心作用 |
|---|---|---|---|
| scrape_interval | 1m | 全局 / Job / 实例 | 控制采集频率，决定数据时间粒度 |
| scrape_timeout | 10s | 全局 / Job / 实例 | 单次采集的最大等待时间，防止挂起 |
| sample_limit | 0（无限制） | 全局 / Job / 实例 | 限制单次采集返回的样本数上限，防止内存爆炸 |
三者之间存在严格的约束关系：scrape_timeout 必须小于 scrape_interval，否则超时设置将失去意义。通常建议 scrape_timeout ≤ scrape_interval × 0.8，为网络抖动和重试预留缓冲。
4.2 Scrape Interval：频率与成本的平衡
采集间隔越短，数据点越密集，但 CPU、内存、网络和存储开销也线性增长。不同场景的推荐配置：
- 基础设施指标（CPU、内存、磁盘）： 15s – 30s。变化较慢，无需过密采集。
- 业务关键指标（QPS、延迟、错误率）： 10s – 15s。需要快速感知异常。
- 高基数指标（HTTP 请求标签、用户维度）： 30s – 60s。降低采集频率以控制样本总量。
- 批处理或离线任务指标： 60s – 120s。任务周期长，高频采集无意义。
4.3 Scrape Timeout：防止采集挂起
超时设置过短会导致正常指标被丢弃；设置过长则可能让采集协程长时间阻塞，耗尽连接池。配置策略如下：
- 基础原则： scrape_timeout = scrape_interval × 0.6 ~ 0.8。
- 对于慢速 exporter（如 SNMP、数据库查询）： 适当放宽超时，但不要超过 scrape_interval 的 90%。
- 对于高并发 exporter： 缩短超时，快速失败，避免排队阻塞。
- 监控超时率： 通过
prometheus_target_scrapes_exceeded_sample_limit_total和prometheus_target_scrapes_timeout_total指标观察超时趋势。
4.4 Sample Limit：内存保护的最后防线
Sample Limit 是防止 Prometheus 内存溢出的关键参数。当某个 exporter 返回的样本数超过限制时，Prometheus 会丢弃该次采集并记录错误，而不是继续处理。
| 场景 | 推荐 sample_limit | 说明 |
|---|---|---|
| 常规 exporter（node_exporter） | 5000 – 10000 | node_exporter 通常返回 2000-5000 个样本 |
| 业务应用（Java、Go 应用） | 10000 – 50000 | 根据业务指标数量调整 |
| 高基数 exporter（kube-state-metrics） | 50000 – 200000 | 需要结合标签基数评估 |
| 未知或不可控 exporter | 5000（保守值） | 先限制，再逐步放宽 |
设置 sample_limit 后，务必监控 prometheus_target_scrapes_exceeded_sample_limit_total 指标。如果该指标持续增长，说明限制过紧，需要分析 exporter 的指标输出并调整限制值。
4.5 三参数协同配置流程
下图展示了从评估到部署的完整配置流程：
4.6 典型配置示例
以下是一个生产环境的 Job 配置示例，展示了三个参数的协同设置：
scrape_configs:
- job_name: 'node_exporter_production'
scrape_interval: 30s
scrape_timeout: 20s
sample_limit: 10000
static_configs:
- targets: ['10.0.1.10:9100', '10.0.1.11:9100']
- job_name: 'business_api_high_freq'
scrape_interval: 10s
scrape_timeout: 8s
sample_limit: 50000
static_configs:
- targets: ['10.0.2.20:8080']
- job_name: 'kube_state_metrics'
scrape_interval: 60s
scrape_timeout: 30s
sample_limit: 200000
static_configs:
- targets: ['10.0.3.30:8080']4.7 参数配置的常见误区
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 全局使用 5s 采集间隔 | CPU 和内存飙升，存储膨胀 12 倍 | 按 Job 差异化设置，默认 30s |
| scrape_timeout = scrape_interval | 采集重叠，协程堆积 | 超时 ≤ 间隔 × 0.8 |
| 不设置 sample_limit | 单个 exporter 异常导致 OOM | 至少设置 5000 作为保护 |
| sample_limit 设置过小 | 正常指标被丢弃，监控缺失 | 监控超限指标，逐步放宽 |
4.8 监控参数效果的指标
部署配置后，通过以下 Prometheus 内置指标验证效果：
prometheus_target_scrapes_exceeded_sample_limit_total— 样本超限次数prometheus_target_scrapes_timeout_total— 采集超时次数prometheus_target_scrapes_sample_duplicate_timestamp_total— 重复时间戳样本数prometheus_target_scrapes_sample_out_of_order_total— 乱序样本数scrape_duration_seconds— 实际采集耗时分布
prometheus_target_scrapes_exceeded_sample_limit_total 和 prometheus_target_scrapes_timeout_total 在 24 小时内保持为 0 或极低值。如果持续增长，说明参数配置需要调整。
4.9 总结
Scrape Interval、Scrape Timeout 和 Sample Limit 是 Prometheus 采集优化的三个核心旋钮。合理的配置策略应遵循以下原则：
- 差异化： 不同 Job 使用不同参数，避免一刀切。
- 留余量： 超时时间必须小于采集间隔，为网络抖动预留空间。
- 设上限： 始终设置 sample_limit，防止异常 exporter 拖垮 Prometheus。
- 可观测： 通过内置指标持续监控采集健康度，形成闭环调优。