当抓取目标较多（如超过 5000 个）且资源出现瓶颈时，单实例 Prometheus 的资源消耗会显著上升，最推荐的处理方向是通过水平分片（Sharding）将负载分散到多个实例，适用于中大型 Kubernetes 集群或物理机环境。

快速处理思路

分片配置主要依赖配置文件调整，核心思路如下：

# 如果使用 Prometheus Operator，在 Prometheus CRD 中设置 shards
spec:
  shards: 2  # 根据目标数量调整分片数

# 应用配置命令
kubectl apply -f prometheus-shard.yaml

# 如果手动配置，使用 hashmod + keep relabeling 分散 target
- source_labels: [__address__]
  action: hashmod
  modulus: 2
  target_label: __shard__
- source_labels: [__shard__]
  action: keep
  regex: 0  # 当前实例只保留 shard 为 0 的目标

为什么会这样

Prometheus 单实例架构在设计上更偏向于可靠性和简单性，而非无限水平扩展。当目标数量增加时，抓取线程竞争、内存中时间序列基数（Cardinality）增长以及 TSDB 写入压力都会线性甚至指数上升。公开资料中没有看到可靠的量化数据表明 5000 是绝对阈值，但这通常是社区经验中单实例资源性价比开始显著下降的拐点，具体阈值需结合硬件配置评估。

分步处理

1. 评估当前负载
查看 Prometheus 自身监控指标，关注抓取延迟和资源使用率。

# 检查目标数量
count(up)

# 检查内存使用
process_resident_memory_bytes

# 检查抓取延迟
prometheus_target_interval_length_seconds

2. 选择分片方案
Kubernetes 环境推荐使用 Prometheus Operator，它原生支持分片配置。物理机环境需手动运行多个实例，并通过服务发现配置不同的分片规则。

3. 配置目标分散
确保每个实例只抓取一部分目标。使用 `hashmod` 动作根据目标地址哈希取模，并配合 `keep` 动作过滤，将目标均匀分配到不同分片。

4. 调整资源限制
为每个分片实例分配独立的内存和 CPU 限制，避免单个分片 OOM 影响整体。

怎么验证是否生效

1. 检查抓取状态
在各分片实例的 Status 页面查看 Targets，确认目标总数被均匀分配，且状态均为 UP。

# 查询当前实例抓取的目标数量
count(up{job="your-job-name"})

2. 监控抓取延迟
查询 `prometheus_target_interval_length_seconds` 指标，确认分片后的抓取延迟低于 scrape_interval 设置。

# 查询 99 分位抓取延迟
prometheus_target_interval_length_seconds{quantile="0.99"}

3. 资源使用观察
观察各分片实例的内存增长曲线，确保没有单个实例异常偏高。

# 对比各实例内存
process_resident_memory_bytes{instance="prometheus-shard-0"}
process_resident_memory_bytes{instance="prometheus-shard-1"}

常见坑

1. 全局查询失效
分片后，单个 Prometheus 不再拥有全量数据。如果需要全局视图，必须引入 Thanos 或 Cortex 等查询层组件，否则 Grafana 面板会显示数据缺失。

2. 服务发现重叠
配置分片规则时，若 relabeling 规则不一致，可能导致多个实例抓取相同目标，造成数据重复。务必确保 `hashmod` 的 `modulus` 和 `keep` 的 `regex` 对应。

3. 配置同步困难
手动分片时，需确保所有实例的配置更新同步，否则容易出现部分目标漏抓。

参考来源

• Prometheus 官方文档 - Scaling: https://prometheus.io/docs/operating/scaling/
• Prometheus Operator 文档 - Sharding: https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/user-guides/sharding.md