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

大规模集群下 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 配置示例

yaml 复制代码

global:
  scrape_interval: 15s
  evaluation_interval: 30s

rule_files:
  - '/etc/prometheus/rules/*.yml'

scrape_configs:
  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        regex: true
        action: keep
      - action: labelmap
        regex: __meta_kubernetes_pod_label_(.+)

  - job_name: 'node-exporter'
    kubernetes_sd_configs:
      - role: node
    metrics_path: /metrics
    relabel_configs:
      - regex: (.+)
        action: labelmap
        replacement: node_$1

# Sidecar remote write
remote_write:
  - url: 'http://thanos-receive:10908/api/v1/receive'
    queue_config:
      max_samples_per_send: 10000
      batch_send_deadline: 5s

3.3 Thanos 组件部署

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

示例 Helm Values（简化）:

yaml 复制代码

thanos:
  sidecar:
    enabled: true
  storeGateways:
    - name: store-gateway-01
      objstoreConfig:
        type: S3
        config:
          bucket: prometheus-data
          endpoint: s3.cn-north-4.myhuaweicloud.com
  compactor:
    retentionResolutionRaw: 6h
    retentionResolution5m: 30d
    compaction:
      downsample:
        resolutionLevels: [5m]
  query:
    replicas: 2

3.4 告警规则与 Alertmanager

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

yaml 复制代码

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

Alertmanager config

yaml 复制代码

route:
  receiver: 'team-notify'
  group_wait: 30s
  group_interval: 5m
  repeat_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 清洗。
yaml 复制代码
```
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 监控架构。欢迎在评论区交流更多实战经验。