大规模集群下 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 配置示例
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 监控架构。欢迎在评论区交流更多实战经验。