1. 课程导论：为什么需要 ServiceMonitor 分片采集？容量校准的核心目标与收益
1.1 单 ServiceMonitor 的容量瓶颈
在 Prometheus Operator 体系中，ServiceMonitor 是定义抓取目标的核心 CRD。默认情况下，一个 ServiceMonitor 会被单个 Prometheus 实例（或单个 StatefulSet Pod）全量采集。当目标规模增长时，会依次出现以下问题：
| 阶段 | 现象 | 根因 |
|---|---|---|
| 采集延迟 | 抓取间隔内无法完成所有 target 的 scrape | 单实例 HTTP 连接池与 goroutine 耗尽 |
| 内存 OOM | Prometheus Pod 频繁 OOMKilled | 全量时间序列在内存中膨胀，超过 limits |
| WAL 写入积压 | WAL 目录磁盘 I/O 打满，查询延迟飙升 | 单实例写入吞吐超过磁盘 IOPS 上限 |
| 查询退化 | PromQL 聚合查询超时或返回不完整 | 单实例 TSDB 块合并与查询争抢 CPU |
容量红线： 社区推荐单 Prometheus 实例管理的活跃时间序列数不应超过 100 万，抓取目标数不应超过 2000 个。超过此阈值，必须引入分片采集。
1.2 分片采集的核心原理
分片采集（Sharding）将原本由一个 ServiceMonitor 定义的抓取目标集合，按 hash(mod) 或 hash(key) 算法均匀分配到多个 Prometheus 实例上。每个实例只采集自己分到的子集，从而实现：
- 水平扩展： 增加分片数即可线性提升采集吞吐。
- 故障隔离： 单个分片故障不影响其他分片的采集链路。
- 资源独立： 每个分片拥有独立的 CPU、内存、磁盘，避免资源争抢。
1.3 容量校准的核心目标
分片不是简单的“多开几个实例”，而是需要精确计算每个分片应承载的采集容量。容量校准的核心目标包括：
- 目标均匀性校准： 确保每个分片分配的 target 数量偏差 < 10%，避免“热点分片”。
- 时间序列密度校准： 根据每个 target 暴露的指标数量（series 密度）加权分配，而非仅按 target 数量。
- 资源预算校准： 为每个分片设定 CPU、内存、磁盘的 request/limit，使其与采集负载匹配。
- 抓取间隔校准： 根据分片负载动态调整
scrape_interval，避免采集超时。 - 故障转移容量校准： 预留 20%~30% 的冗余容量，确保单分片故障后其他分片可接管。
关键公式： 分片数 = ceil( 总目标数 × 平均 series 密度 / 单分片安全容量 )
其中单分片安全容量通常取 50 万时间序列（留有余量）。
其中单分片安全容量通常取 50 万时间序列（留有余量）。
1.4 容量校准的核心收益
| 收益维度 | 具体表现 | 量化指标 |
|---|---|---|
| 采集可靠性 | 抓取成功率从 95% 提升至 99.9%+ | scrape_samples_scraped 无断点 |
| 资源利用率 | CPU/内存使用率稳定在 60%~75% | 避免低负载浪费或高负载 OOM |
| 查询性能 | P99 查询延迟降低 50%~70% | TSDB 块合并不再争抢 CPU |
| 运维效率 | 分片扩缩容可通过修改 replicas 完成 |
无需手动迁移 target |
| 成本控制 | 精确匹配资源预算，避免过度预留 | 集群总资源节省 20%~40% |
1.5 何时需要启动分片采集容量校准？
以下场景出现任意一个，即应启动容量校准流程：
- 指标增长： 单
ServiceMonitor管理的活跃时间序列数超过 50 万（预警线）。 - 采集超时：
scrape_duration_seconds的 P99 超过scrape_interval的 80%。 - 资源过载： Prometheus 容器 CPU 使用率持续 > 80%，或内存使用率 > 70%。
- 查询退化： 常用仪表盘加载时间超过 10 秒，或 PromQL 聚合查询频繁超时。
- 业务扩容： 计划新增 30% 以上的监控目标（如新集群上线）。
最佳实践： 建议在每次业务大版本发布前，执行一次 ServiceMonitor 分片采集容量校准，作为容量保障的例行巡检项。