Prometheus之基本原理
通过 「电力监控系统」 类比 + 分层架构图，直观说明其核心原理：
一、Prometheus 核心定位
⚡ 比喻：智能电网监控中心
- 每个家庭（服务）装有电表（Exporter），Prometheus 是定时抄表（Pull）、存储用电曲线（时间序列）、分析异常用电（Alert）的「中央监控大脑」。
二、核心架构图例
+---------------------+
| Prometheus |
| (监控中心) |
+----------+----------+
| Pull (主动抄表)
+---------------------------+---------------------------+
| | |
+--------+---------+ +---------+---------+ +---------+---------+
| Exporter | | Exporter | | Exporter |
| (电表) | | (电表) | | (电表) |
| - Node Exporter | | - MySQL Exporter | | - App Exporter |
| (CPU/内存) | | (DB状态) | | (业务指标) |
+------------------+ +-------------------+ +-------------------+
▲ ▲ ▲
│ 实际指标 (电压/电流) │ 实际指标 (查询延迟) │ 实际指标 (订单量)
│ │ │
+------------------+ +-------------------+ +-------------------+
| 被监控目标 | | 被监控目标 | | 被监控目标 |
| - 服务器 | | - MySQL | | - 订单服务 |
+------------------+ +-------------------+ +-------------------+核心组件解析：
Exporter（电表）：
- 作用：将目标（服务器/DB/应用）的指标暴露为 Prometheus 可读的 HTTP 接口（如
http://host:9100/metrics）。 常见类型：
Node Exporter：监控服务器资源（CPU/内存/磁盘）。MySQL Exporter：监控数据库状态（连接数/慢查询）。自定义 Exporter：暴露业务指标（如订单数/错误率）。
- 作用：将目标（服务器/DB/应用）的指标暴露为 Prometheus 可读的 HTTP 接口（如
Prometheus Server（监控中心）：
- 拉取模型（Pull）：主动定时（如 15s）从 Exporter 拉取指标数据。
- 时序数据库（TSDB）：高效存储时间序列数据（指标名 + 时间戳 + 值）。
- 服务发现：自动发现 Kubernetes/Docker 等动态目标。
Alertmanager（告警调度台）：
- 接收告警：处理 Prometheus 触发的报警规则（如 CPU > 80% 持续 5min）。
- 路由去重：按标签路由给不同团队（短信/邮件/钉钉），合并重复告警。
Grafana（可视化大屏）：
- 连接 Prometheus：绘制实时仪表盘（CPU 负载曲线、错误率热力图）。
三、关键概念图解
1. 时间序列数据模型
指标名：http_requests_total
标签（设备ID/状态）：{method="POST", path="/order", status="200"}
数据点：
(时间戳 1600000000 → 值 42)
(时间戳 1600000015 → 值 57) 组成要素：
指标名：测量对象（如http_requests_total）。标签：维度标识（如method="GET",status="404"）。时间戳 + 值：某一时刻的测量值。
💡 比喻：
- 时间序列 = 电表每天记录的「用电量曲线」
- 标签 = 电表所属的「楼层/房间号」
2. 四种核心指标类型
| 类型 | 含义 | 示例 | 类比 |
|---|---|---|---|
| Counter（计数器） | 只增不减（累计值） | HTTP 请求总数 | 电表总用电量（累加） |
| Gauge（仪表盘） | 可升可降（瞬时值） | CPU 使用率 | 实时电压值 |
| Histogram（直方图） | 采样分布（如分位数） | 请求延迟分布（P90/P99） | 电压波动区间统计 |
| Summary（摘要） | 客户端计算的分布（更精准） | 同上，但计算在客户端 | 电表本地统计报告 |
四、工作流程详解
1. 数据采集与存储流程
1. Prometheus Server 定时（15s）向 Exporter 发送 HTTP 请求：
GET http://node-exporter:9100/metrics
2. Exporter 返回当前指标数据：
node_cpu_seconds_total{cpu="0", mode="idle"} → 1000.5
node_memory_free_bytes → 2048000000
3. Prometheus 存储数据到 TSDB：
┌───────────────────┬────────────┬───────┐
│ Metric + Labels │ Timestamp │ Value │
├───────────────────┼────────────┼───────┤
│ node_cpu_seconds..│ 1600000000 │ 1000.5│
│ node_memory_free..│ 1600000000 │ 2.04e9│
└───────────────────┴────────────┴───────┘2. 告警触发流程
Prometheus Server 中定义告警规则：
ALERT HighCPU
IF node_cpu_usage > 80% ← 持续5分钟
LABELS { severity="critical" }
触发流程：
Prometheus Server → 评估规则 → 触发告警 → 推送至 Alertmanager → 路由去重 → 发送邮件3. PromQL 查询示例
查询1：实时CPU使用率
100 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100
查询2：HTTP错误率（5分钟内）
sum(rate(http_requests_total{status!~"2.."}[5m]))
/
sum(rate(http_requests_total[5m]))💡 比喻：
- PromQL = 电力分析师写的「用电报告公式」
rate()= 计算每秒用电增长率sum()= 整栋楼总用电量
五、技术优势总结
| 特性 | 实现方式 | 用户价值 |
|---|---|---|
| 主动拉取（Pull） | 定时从 Exporter 拉取数据 | 避免被监控目标过载 |
| 强大的查询语言 | PromQL 灵活聚合分析 | 1行代码计算复杂指标 |
| 多维数据模型 | 指标 + 标签自由组合 | 按任意维度切片分析 |
| 原生集成 Kubernetes | 自动发现 Pod/Service | 动态监控容器化环境 |
🔧 生产贴士：
- 长期存储：集成 Thanos 或 Cortex 解决历史数据存储问题
- 高可用：部署多个 Prometheus + Alertmanager 集群
六、典型监控场景
+----------------+ +----------------+ +----------------+
| 基础设施监控 | | 微服务监控 | | 业务指标监控 |
| (CPU/内存/磁盘) | | (请求延迟/错误率) | | (订单量/支付成功率)|
| | | | | |
| Node Exporter | | Spring Actuator| | 自定义 Exporter |
+--------+-------+ +--------+-------+ +--------+-------+
| | |
v v v
+-----------------------------------------------------------------------+
| Prometheus Server |
+-----------------------------------------------------------------------+
| | |
v v v
+----------------+ +----------------+ +----------------+
| Grafana | | Alertmanager | | 长期存储 |
| (实时仪表盘) | | (告警通知) | | (Thanos) |
+----------------+ +----------------+ +----------------+通过此架构，Prometheus 实现了从 「硬件指标」→「应用性能」→「业务状态」 的全栈监控覆盖。