Prometheus 大规模集群监控优化指南

Prometheus 在单实例场景下表现优秀，但当监控目标超过 10 万级时，采集延迟、存储膨胀和查询卡顿会逐步暴露。大规模集群监控优化不是简单地加机器，而是需要从架构层面解决数据的"采、存、查、警"四个问题。本文从联邦分片、Thanos 长期存储、告警降噪和 USE/RED 方法论四个维度给出优化路径。

一、联邦分片：解决单实例采集瓶颈

Prometheus 的单实例架构在监控目标超过 5000 到 10000 个时会遇到采集间隔拉长的问题。当 scrape targets 过多时，每个目标的采集周期被拉长，原本 15 秒的间隔可能变成 30 秒甚至更久，导致指标粒度下降。联邦（Federation）和分片（Sharding）是两种互补的方案。

水平分片： 将监控目标按维度（如集群、机房、业务线）分配到多个 Prometheus 实例上，每个实例只采集自己负责的目标。这种方式简单直接，但需要在查询时聚合多个实例的数据。用 Prometheus 的 honor_labels: true 配置确保不同实例上同名指标的 label 不被覆盖。分片的维度选择很关键——按集群分片适合多集群架构，按业务线分片适合微服务架构，按地域分片适合跨地域部署。选择不当会导致某些查询需要跨多个分片聚合，反而增加查询延迟。

联邦模式： 在分片层之上部署一台联邦 Prometheus，通过 /federate 端点从各分片 Prometheus 拉取聚合后的指标。联邦层只拉取需要全局视野的指标（如集群级别的汇总指标），不拉取所有原始数据，避免联邦层成为新的瓶颈。联邦查询的性能取决于联邦层的内存和 CPU——如果拉取的指标过多，联邦层本身会成为单点。建议联邦层只聚合关键的 recording rules 结果，而不是原始指标。

推荐架构为两层结构：第一层是 3 到 5 个分片 Prometheus，每个负责一个维度的监控目标；第二层是 1 到 2 个联邦 Prometheus，只聚合关键指标。查询时根据指标来源选择对应分片的 Prometheus，全局指标走联邦层。这种架构在实际生产中可以支撑数十万级监控目标的采集需求。

标签基数控制： 高基数标签（如 user_id、request_id）是 Prometheus 的天敌。每个唯一的标签组合都会创建一个新的时间序列，100 个 instance 乘以 1000 个 user_id 等于 10 万个时间序列。使用 relabel_config 在采集阶段过滤或聚合高基数标签，将 user_id 替换为 user_bucket（如 user_0xxx、user_1xxx）可以将时间序列数量降低 1 到 2 个数量级。判断标签基数是否过高的方法是用 topk(10, count by (__name__)({__name__=~".+"})) 查看每个指标名的时间序列数量，超过 1 万个的需要重点关注。

二、Thanos：解决长期存储与全局查询

Prometheus 的本地存储默认只保留 15 天（--storage.tsdb.retention.time），对于需要历史趋势分析和合规审计的场景远远不够。Thanos 通过对象存储实现了无限期的长期存储。

Sidecar 模式： 在每个 Prometheus 实例旁部署一个 Thanos Sidecar，将 TSDB 数据块定期上传到对象存储（如 S3、COS、MinIO）。Sidecar 不影响 Prometheus 的正常采集和查询，只是额外做数据上传。Sidecar 上传的数据块是只读的，不会修改 Prometheus 的本地数据。上传间隔默认为 5 分钟，可以通过 --shipper.upload-compacted 参数控制是否上传压缩后的数据块。

Store Gateway： 从对象存储中读取历史数据，对查询层提供与本地 Prometheus 相同的 PromQL 接口。查询近期数据走本地 Prometheus，查询历史数据走 Store Gateway，实现透明的混合查询。Store Gateway 会在本地缓存频繁访问的索引和数据块，减少对对象存储的重复请求。缓存大小由 --store.grpc.series-max-concurrency 控制，默认为 1000。

Compact： Thanos Compactor 负责对对象存储中的数据块进行压缩和降采样。原始数据（5 分钟粒度）保留 30 天，1 小时降采样数据保留 1 年，5 分钟降采样数据永久保留。这样既保证了近期查询的精度，又控制了长期存储的体积。Compact 的运行频率建议每天一次，在对象存储的低峰期执行。需要注意的是，Compact 是有状态操作，不建议同时运行多个 Compact 实例。

Querier： 提供全局查询视图，自动将 PromQL 查询路由到最近的 Prometheus 实例或 Store Gateway，对用户透明。Querier 还支持 dedup（去重）功能，当多个 Sidecar 上传了相同的数据块时，Querier 会自动去重，避免重复计算。

三、告警降噪：从海量告警到有效告警

大规模集群最常见的问题不是没有告警，而是告警太多导致"告警疲劳"。当运维人员每天收到上百条告警时，真正的问题会被淹没在噪声中。降噪不是降低告警灵敏度，而是让告警更精准。

分层告警： 将告警分为 P0（需要立即处理）、P1（1 小时内处理）、P2（当天处理）三个级别。P0 告警必须有明确的影响范围和处理流程，P2 告警可以合并为日报。通过 Prometheus 的 for 持续时间和 Alertmanager 的 group_wait、group_interval 参数实现分级。例如 P0 级别设置 for: 1m、group_wait: 10s、repeat_interval: 5m，确保严重问题在 1 分钟内触发通知；P1 级别设置 for: 5m、group_wait: 30s、repeat_interval: 30m；P2 级别设置 for: 15m、group_wait: 5m、repeat_interval: 4h。

去重与抑制： Alertmanager 的 inhibit_rules 可以在低级别告警触发时自动抑制高级别告警的重复通知。比如当 P0 告警触发时，自动抑制同一实例上的 P1 和 P2 告警，避免告警风暴。另外，当一个服务的多个实例同时告警时，通过 group_by 将它们合并为一条通知，而不是每个实例发一条。

基于 SLO 的告警： 用 Prometheus 的 recording rules 预计算服务的 SLI（如请求成功率、延迟百分位），然后基于 SLI 与 SLO 的偏差触发告警，而不是基于原始指标的绝对阈值。这种方式天然过滤了正常波动，大幅减少误报。例如，如果 SLO 要求请求成功率不低于 99.9%，那么只有当 SLI 低于 99.9% 时才触发告警，而不是在每次错误请求时都触发。

四、USE/RED 方法论：从指标覆盖到指标精简

大规模集群的指标采集不能"全采"，需要有方法论指导。USE 方法论（Utilization、Saturation、Errors）适用于基础设施监控，RED 方法论（Rate、Errors、Duration）适用于服务监控。

USE 用于节点和容器： 对每个资源（CPU、内存、磁盘、网络），只采集利用率（utilization）、饱和度（saturation）和错误数（errors）三类指标。以 CPU 为例，只需要 node_cpu_seconds_total（利用率）、node_load1（饱和度）、node_edac_correctable_errors_total（错误数），不需要采集 CPU 的每一个细分状态。内存的关键指标是 node_memory_MemAvailable_bytes（可用内存）和 node_vmstat_pgmajfault（主缺页次数，反映内存压力）。磁盘的关键指标是 node_disk_io_time_seconds_total（IO 利用率）和 node_disk_io_time_weighted_seconds_total（IO 饱和度）。

RED 用于服务： 对每个服务，只采集请求速率（rate）、错误率（errors）和延迟分布（duration）。用 rate(http_requests_total[5m]) 计算请求速率，用 rate(http_requests_total{status=~"5.."}[5m]) 计算错误率，用 histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) 计算 P99 延迟。这三个指标足以评估一个服务的健康状态，不需要采集每个接口的详细指标。

指标精简的收益： 通过 USE/RED 方法论精简指标后，Prometheus 的时间序列数量可以减少 30% 到 50%，采集和存储成本相应降低。同时，精简后的指标集更易于理解和维护，告警规则也更清晰。

YCOS 统一运维可观测平台融合指标、日志、链路三大支柱，兼容 Prometheus、Skywalking、OpenTelemetry 协议，提供全链路监控、根因定位与 AI 辅助决策能力，在大规模集群场景下可以帮助统一管理分散的 Prometheus 实例和告警规则，降低多集群监控的运维复杂度。

优化路径总结

Prometheus 大规模集群监控优化的核心是"分而治之"：用联邦分片解决采集瓶颈，用 Thanos 解决存储瓶颈，用告警降噪和 SLO 解决通知瓶颈，用 USE/RED 方法论解决指标覆盖与精简的平衡问题。四个维度不是独立的——联邦分片的数据需要 Thanos 管理长期存储，精简后的指标需要告警规则与之匹配，形成一个完整的监控体系。

如果你的 Prometheus 集群当前采集的指标超过 50 万个时间序列，建议按以下顺序优化：首先用 USE/RED 方法论梳理指标覆盖范围，去掉无用指标；然后实施联邦分片，将采集负载分散到多个实例；接着部署 Thanos 解决长期存储问题；最后建立分层告警机制，让每条告警都值得被关注。