Prometheus 架构与核心组件详解

Prometheus 架构与核心组件详解

Prometheus 是一个开源的系统监控和警报工具包，其架构设计简洁、高效，特别适合云原生和微服务环境。它采用拉取模型（Pull-based）、多维数据模型和本地时间序列数据库（TSDB），形成了一个自包含、可扩展的监控系统。

本文将深入解析 Prometheus 的整体架构及其核心组件，帮助你理解其工作原理、数据流和组件协作机制。

---

一、Prometheus 整体架构图

---

二、核心组件详解

1. Prometheus Server（主服务器）

这是 Prometheus 的核心组件，负责：

• 发现监控目标（Targets）
• 定期拉取（Scrape）指标数据
• 存储到本地时间序列数据库（TSDB）
• 执行 PromQL 查询
• 评估告警规则

主要子模块

子模块	功能
Retrieval（抓取模块）	负责从目标服务拉取 /metrics 数据
Storage（存储模块）	将样本写入本地 TSDB（Time Series Database）
PromQL Engine（查询引擎）	解析和执行 PromQL 查询
Rule Evaluation（规则引擎）	定期评估记录规则（Recording Rules）和告警规则（Alerting Rules）

📌 Prometheus Server 是单进程、单节点设计，不自带高可用（HA），需通过 Thanos、Cortex 等扩展。

---

2. Targets（监控目标）

指被 Prometheus 监控的服务实例，通常是：

• HTTP 服务（如 Spring Boot 应用）
• Exporter（如 Node Exporter、MySQL Exporter）
• Kubernetes Pod、Service

指标暴露方式

目标服务需暴露一个 HTTP 端点（默认 /metrics），返回文本格式的指标数据，例如：

# HELP http_requests_total Total number of HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="GET",status="200"} 1024
http_requests_total{method="POST",status="500"} 3

✅ 常见实现：Micrometer、Prometheus Client Libraries

---

3. Service Discovery（服务发现）

Prometheus 支持多种动态服务发现机制，自动发现监控目标，无需手动配置 IP。

内置服务发现类型

类型	说明
kubernetes_sd_configs	自动发现 Kubernetes 中的 Pod、Service、Endpoint
consul_sd_configs	从 Consul 注册中心发现服务
ec2_sd_configs	发现 AWS EC2 实例
dns_sd_configs	通过 DNS 记录发现服务
file_sd_configs	从本地文件（JSON/YAML）加载目标列表

示例：Kubernetes 服务发现

- job_name: 'kubernetes-pods'
  kubernetes_sd_configs:
    - role: pod
  relabel_configs:
    - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
      action: keep
      regex: true

✅ 自动发现所有带有 prometheus.io/scrape: "true" 注解的 Pod

---

4. Retrieval（抓取模块）

负责定期从目标服务拉取指标数据。

工作流程

1. 根据 scrape_interval（默认 15s）发起 HTTP GET 请求
2. 从目标的 /metrics 端点获取指标文本
3. 解析并转换为时间序列样本
4. 写入本地 TSDB

配置示例

scrape_configs:
  - job_name: 'node'
    scrape_interval: 15s
    static_configs:
      - targets: ['192.168.1.10:9100']

⚠️ 抓取频率越高，性能开销越大，需权衡。

---

5. Storage（存储模块）——本地 TSDB

Prometheus 使用自带的时间序列数据库（TSDB） 存储指标数据。

存储机制

• 数据按 2 小时 block 存储在磁盘
• 使用 WAL（Write-Ahead Log） 保证写入可靠性
• 支持 压缩 和 快速查询
• 默认保留 15 天（可配置）

存储目录结构

data/
├── 01GXQJQZQKQZQKQZQKQZQKQZQK  # Block 1
│   ├── chunks/
│   ├── index
│   └── meta.json
├── 01GXQJQZQKQZQKQZQKQZQKQZQK+1
└── wal/                         # Write-Ahead Log
    ├── 00000001
    └── 00000002

✅ 优势：高性能、低延迟
❌ 限制：单节点，不支持水平扩展（需 Thanos/Cortex）

---

6. PromQL Engine（查询引擎）

Prometheus 的查询语言 PromQL（Prometheus Query Language） 是其分析能力的核心。

支持的查询类型

类型	示例
即时向量（Instant Vector）	http_requests_total{job="api"}
范围向量（Range Vector）	http_requests_total[5m]
聚合操作	sum by (method) (http_requests_total)
函数	rate(), irate(), histogram_quantile()

示例：计算 99 分位延迟

histogram_quantile(0.99, 
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
)

✅ 查询引擎直接访问本地 TSDB，响应速度快

---

7. Rule Evaluation（规则引擎）

定期评估两类规则：

（1）Recording Rules（记录规则）

预计算复杂查询，提升查询性能。

groups:
  - name: example
    rules:
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))

✅ 将结果存储为新指标，供后续查询使用

（2）Alerting Rules（告警规则）

定义何时触发告警。

- alert: HighRequestLatency
  expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 1
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "High latency on {{ $labels.instance }}"

✅ 规则评估通过后，发送告警到 Alertmanager

---

8. Alertmanager（告警管理器）

独立于 Prometheus Server 运行，负责告警的去重、分组、静默、抑制和通知。

核心功能

功能	说明
去重（Deduplication）	相同告警在一段时间内只通知一次
分组（Grouping）	将相似告警合并发送（如多个实例宕机）
静默（Silences）	临时屏蔽告警（如维护期）
抑制（Inhibition）	某告警触发时，抑制其他相关告警
通知（Notifications）	支持 Email、Slack、Webhook、PagerDuty 等

配置示例

route:
  group_by: [alertname]
  receiver: 'slack-notifications'
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty'

receivers:
  - name: 'slack-notifications'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/...'

✅ 生产环境必须部署 Alertmanager

---

9. Exporters（导出器）

用于将第三方系统指标转换为 Prometheus 格式。

常见 Exporter

Exporter	监控目标
Node Exporter	主机 CPU、内存、磁盘、网络
MySQL Exporter	MySQL 数据库指标
Redis Exporter	Redis 内存、命令数、连接数
cAdvisor	容器资源使用（已集成进 kubelet）
Blackbox Exporter	黑盒探测（HTTP、DNS、TCP）

✅ 所有 Exporter 都暴露 /metrics 端点

---

10. Pushgateway（推送网关）

用于支持 Push 模型 的短生命周期任务（如批处理作业）。

使用场景

• 定时任务（CronJob）
• 短时脚本
• 无法被拉取的服务

工作方式

1. 任务完成后，将指标 POST 到 Pushgateway
2. Prometheus 定期从 Pushgateway 拉取数据

echo "job_duration_seconds 123" | curl --data-binary @- http://pushgateway:9091/metrics/job/cronjob

⚠️ 不要用于常规服务监控（破坏拉取模型一致性）

---

三、Prometheus 生态组件关系图

---

四、数据流总结

1. 服务发现 → 找到目标实例
2. Retrieval → 定期拉取 /metrics
3. Storage → 写入本地 TSDB
4. Rule Evaluation → 计算记录规则和告警规则
5. PromQL Engine → 提供查询接口
6. Alertmanager → 接收告警并发送通知
7. Grafana → 可视化展示

---

五、架构优势与局限

✅ 优势

优势	说明
简单易用	单二进制文件，易于部署
高性能	本地 TSDB，查询延迟低
多维模型	支持灵活的标签查询
拉取模型	易于调试，适合云环境
丰富生态	Exporter、Alertmanager、Grafana 集成

❌ 局限

局限	解决方案
不支持高可用	使用 Thanos、Cortex
存储有限	结合对象存储（S3/GCS）
无原生长期存储	Thanos Bucket、Cortex
不适合日志/链路	需 Loki、Tempo 等

---

六、最佳实践建议

1. ✅ 使用 relabel_configs 清理无用标签
2. ✅ 合理设置 scrape_interval（15s/30s）
3. ✅ 避免高基数标签（如 user_id）
4. ✅ 生产环境必配 Alertmanager
5. ✅ 使用 Recording Rules 优化复杂查询
6. ✅ 结合 Grafana 实现可视化
7. ✅ 长期存储使用 Thanos 或 Cortex

---

七、总结

Prometheus 的架构设计体现了“简单、可靠、可组合”的哲学：

• Prometheus Server 是核心，负责抓取、存储、查询、告警
• Service Discovery 实现动态监控
• TSDB 提供高效本地存储
• PromQL 支持强大分析
• Alertmanager 完善告警闭环
• Exporters / Pushgateway 扩展监控范围

通过理解其架构与核心组件，你可以更好地设计和运维一个稳定、高效、可扩展的监控系统，为云原生应用保驾护航。

📌 官方文档：https://prometheus.io/docs/