大规模集群下 Prometheus 监控架构实战经验分享

1 业务场景描述

在互联网金融业务发展过程中，我们需要对数千台主机、上万容器与微服务实例进行指标监控，并统计历史数据以支持 SLA 报表、告警与容量规划。传统监控系统面临以下挑战：

实例动态扩缩容，IP 地址和端口不断变动。
指标数据量暴增，Prometheus 单节点存储和查询性能瓶颈明显。
高可用需求，对告警推送和报警规则执行有严格响应时效。
历史指标留存周期长达 90 天，单机磁盘成本不可控。

基于上述场景，我们选型 Prometheus 作为度量与告警引擎，结合 Thanos 组件实现长时数据存储与查询叠加，打造高可用、可水平扩展的监控平台。

2 技术选型过程

Prometheus：云原生时代事实标准，支持多种服务发现、告警规则、录制规则，生态成熟。
Thanos：在 Prometheus 之上提供全球视图查询、对象存储长时存储、横向扩容与高可用。
Alertmanager：灵活路由与抑制策略，集成短信、邮件、Webhook 推送。
Pushgateway：支持短命 Job 指标上报，补充拉取模型在批量任务场景的不足。
服务发现：结合 Kubernetes API、Consul、文件SD、DNS-SD 满足多种环境。

与其他方案对比：

InfluxDB+Telegraf：写入吞吐高，但查询语言不标准、告警生态不足。
ELK+Metricbeat：日志型指标存储，性能与成本局限明显。

最终决定以 Prometheus+Thanos 为核心技术栈，兼容原生生态与社区方案。

3 实现方案详解

3.1 架构整体设计

+----------------------+      +-------------+      +-----------------+
|  Kubernetes / VM 集群 | <--> | Prometheus  | <--> | Thanos Sidecar  |
+----------------------+      +-------------+      +-----------------+|                      |v                      v+-----------------+      +-----------------+|   Thanos Store  | <--->|  对象存储（S3） |+-----------------+      +-----------------+|v+-----------------+|   Thanos Query  |+-----------------+|v+-----------------+|  Grafana / UI   |+-----------------+

Prometheus 多副本部署，Sidecar 与远程存储对接。
Thanos Store Gateway 通过对象存储块读取历史数据。
Thanos Query 聚合各 Prometheus Server 与 Store，提供统一查询接口。
Alertmanager 集群模式，配置多分组通知策略。

3.2 Prometheus 配置示例

global:scrape_interval: 15sevaluation_interval: 30srule_files:- '/etc/prometheus/rules/*.yml'scrape_configs:- job_name: 'kubernetes-pods'kubernetes_sd_configs:- role: podrelabel_configs:- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]regex: trueaction: keep- action: labelmapregex: __meta_kubernetes_pod_label_(.+)- job_name: 'node-exporter'kubernetes_sd_configs:- role: nodemetrics_path: /metricsrelabel_configs:- regex: (.+)action: labelmapreplacement: node_$1# Sidecar remote write
remote_write:- url: 'http://thanos-receive:10908/api/v1/receive'queue_config:max_samples_per_send: 10000batch_send_deadline: 5s

3.3 Thanos 组件部署

Sidecar：与 Prometheus 同一 Pod 部署，自动发现和上传 TSDB 块。
Store Gateway：读取对象存储中的块，实现长时存储查询。
Compactor：定期压缩历史数据，合并小块，提高查询效率。
Query：聚合 Prometheus 与 Store，实现全局视图。

示例 Helm Values（简化）:

thanos:sidecar:enabled: truestoreGateways:- name: store-gateway-01objstoreConfig:type: S3config:bucket: prometheus-dataendpoint: s3.cn-north-4.myhuaweicloud.comcompactor:retentionResolutionRaw: 6hretentionResolution5m: 30dcompaction:downsample:resolutionLevels: [5m]query:replicas: 2

3.4 告警规则与 Alertmanager

示例告警规则 (/etc/prometheus/rules/alerts.yml)

groups:- name: node.rulesrules:- alert: NodeDiskAlmostFullexpr: node_filesystem_free_bytes / node_filesystem_size_bytes < 0.1for: 5mlabels:severity: warningannotations:summary: "{{ $labels.instance }} 磁盘使用率过高"description: "磁盘剩余少于10%，请及时清理或扩容。"

Alertmanager config

route:receiver: 'team-notify'group_wait: 30sgroup_interval: 5mrepeat_interval: 2h
receivers:- name: 'team-notify'wechat_configs:- to_user: 'devops'api_url: 'https://qyapi.weixin.qq.com/cgi-bin/message/send'

4 踩过的坑与解决方案

高基数（cardinality）爆炸
- 问题：错误地将动态标签（如用户 ID、订单号）暴露给 Prometheus，导致 TSDB 索引暴涨。
- 解决：通过 relabel_configs 丢弃非必需标签，使用 drop_labels 清洗。
```
relabel_configs:- source_labels: [order_id]action: labeldrop
```
查询延迟与内存溢出
- 问题：PromQL 聚合大范围时间窗口时，Prometheus 内存占用剧增。
- 解决：
  - 使用 Thanos Query 限制下推参数；
  - 针对复杂报表提前录制录制规则（Recording Rules）；
  - 合理设置 max_concurrent_queries。
对象存储 IO 瓶颈
- 问题：Compactor 与 Store Gateway 同时访问 S3，带宽耗尽。
- 解决：
  - 引入缓存层，如 MinIO 网关；
  - 拆分 Compactor 时段，与高峰查询时段错峰执行；
  - 使用网络带宽 QoS 分流。
Alertmanager 集群状态不一致
- 问题：多副本间配置信息不同步，导致告警漏报。
- 解决：统一配置存储（GitOps 管理），并使用 Consul 或 KV 存储做服务发现与配置同步。

5 总结与最佳实践

统一指标规范：提前设计 Label 维度，避免高基数。
录制规则优先：Apdex、率类指标预先计算，降低在线计算资源消耗。
分层架构：将短期数据留存在本地 Prometheus，长时数据交给 Thanos 压缩与存储。
异步告警：告警与主链路隔离，避免监控系统自身故障导致告警丢失。
监控自检：Prometheus 自身指标也要纳入监控，如 prometheus_target_interval_length_seconds。

完整项目结构示例：

prometheus-stack/
├─ prometheus/
│  ├─ config/
│  │  ├─ prometheus.yml
│  │  └─ rules/
│  │     └─ alerts.yml
│  └─ Dockerfile
├─ thanos/
│  ├─ compactor/
│  ├─ store-gateway/
│  └─ query/
└─ helm-values.yaml

通过上述设计与优化，我们在生产环境中实现了秒级发现、数小时内查询 TB 级别历史指标、子服务告警 15s 内送达的目标，为业务运维与容量规划提供了有力支撑。

本文结合真实生产案例，旨在帮助中大型团队快速上手并优化 Prometheus 监控架构。欢迎在评论区交流更多实战经验。