Prometheus 基础原理

Prometheus 可以说是现代 SRE / 云原生体系的核心组件之一。

1. Prometheus 是什么？

一句话：

Prometheus 是一个开源的监控系统和时序数据库（TSDB），用于采集、存储、查询和分析随时间变化的指标数据。

它最初由 SoundCloud 开发，后来成为 CNCF 项目。

它解决的问题：

传统监控：

服务器
 |
脚本采集
 |
数据库
 |
报警

云原生时代：

容器数量动态变化

服务自动扩缩容

实例随时创建销毁

微服务数量巨大

传统监控很难适应。

Prometheus 的设计目标：

面向动态基础设施的指标监控系统。

2. Prometheus 在整个监控体系中的位置

完整链路：

          应用

           |
           |
       暴露Metrics

           |
           |
       Exporter

           |
           |
       Prometheus

           |
           |
      TSDB存储

           |
           |
       PromQL查询

           |
     ----------------

     |              |

  Grafana       AlertManager

                    |

              告警通知

例如 K3s 监控环境：

k3s

 |
 |
node-exporter
 |
 |
Prometheus
 |
 |
Grafana

常见部署组件包括：

monitoring-prometheus-node-exporter
monitoring-grafana
kube-state-metrics

就是这个体系。

3. Prometheus 最核心的设计：Pull 模型

这是它和很多传统监控最大的区别。

3.1. 传统监控 Push

例如：

服务器

主动发送

↓

监控服务器

比如：

agent
 |
 |
push
 |
 |
server

问题：

agent管理复杂
网络权限复杂
大量机器主动连接

3.2. Prometheus Pull

Prometheus 主动拉取：

              Prometheus

                   |
                   |
              HTTP GET

                   |

        -----------------

        |               |

    node-exporter    app metrics

例如：

Prometheus 每隔15秒：

访问：

http://node01:9100/metrics

获取：

cpu_usage 30

memory_usage 60

disk_usage 70

优势：

3.3. 服务发现方便

Kubernetes：

Pod动态变化：

pod1
pod2
pod3

↓

pod4新增

↓

Prometheus自动发现

3.4. Prometheus 控制采集频率

例如：

scrape_interval: 15s

统一控制。

3.5. 更容易检测故障

如果：

Prometheus访问不到Exporter

直接：

up=0

4. Prometheus 架构

详细看：

                  Prometheus Server

                        |
        --------------------------------

        |              |              |

   ServiceDiscovery   Scraper      TSDB

                        |

                     Metrics

                        |

                   Query Engine

                        |

                    PromQL

4.1. Prometheus Server

核心组件。

负责：

拉取指标
存储数据
执行查询
规则计算

4.2. Scrape

采集过程。

例如：

配置：

scrape_interval: 15s

表示：

每15秒访问一次：

/metrics

例如：

node-exporter：

GET

http://node01:9100/metrics

node_cpu_seconds_total 12345

node_memory_bytes 98765

4.3. TSDB

Time Series Database。

时序数据库。

存储：

指标名称

+

标签

+

时间戳

+

值

例如：

cpu_usage{
instance="node01"
}

30

timestamp:
1720000000

5. Prometheus 数据模型

Prometheus 不存：

CPU=50

而存：

Metric + Labels

例如：

node_cpu_seconds_total{
instance="10.0.0.17:9100",
cpu="0",
mode="idle"
}

拆开：

5.1. Metric name

指标名称：

node_cpu_seconds_total

表示：

CPU累计时间。

5.2. Labels

标签：

instance="node01"

cpu="0"

mode="idle"

作用：

区分不同数据。

例如：

同一个指标：

cpu_usage

可以有：

cpu_usage{
host="node01"
}

cpu_usage{
host="node02"
}

这也是 Prometheus 强大的原因。

6. 四种 Metric 类型

这是必须掌握的。

6.1. Counter（计数器）

特点：

只增不减。

例如：

HTTP请求总数：

http_requests_total

数据：

不会：

500

300

除非重启。

用途：

请求数量
错误数量
网络流量

例如：

PromQL：

计算QPS：

rate(http_requests_total[5m])

意思：

过去5分钟增长速度。

6.2. Gauge（仪表盘）

特点：

可以上下变化。

例如：

CPU：

内存：

60%

70%

80%

常用：

CPU
Memory
温度
当前连接数

6.3. Histogram

用于：

统计分布。

例如：

接口耗时：

10ms
20ms
100ms
1s

生成：

http_request_duration_seconds_bucket

用于计算：

P95/P99。

例如：

histogram_quantile(
0.99,
rate(http_request_duration_seconds_bucket[5m])
)

得到：

P99=500ms

6.4. Summary

类似 Histogram。

也可以计算：

P95

P99

区别：

Histogram：

服务端计算。

Summary：

客户端计算。

生产更常用 Histogram。

7. Exporter 是什么？

Prometheus 本身不会读取系统信息。

它需要：

Exporter。

结构：

Linux

 |

node-exporter

 |

/metrics

 |

Prometheus

例如：

访问：

http://node01:9100/metrics

看到：

node_cpu_seconds_total

node_memory_MemAvailable_bytes

node_filesystem_avail_bytes

常见 Exporter：

Exporter	作用
node-exporter	Linux
mysqld-exporter	MySQL
redis-exporter	Redis
kube-state-metrics	K8s对象
blackbox-exporter	网络探测

8. Kubernetes 中的 Prometheus

当前 kube-prometheus-stack 环境常见组件包括：

kube-prometheus-stack

它包含：

Prometheus Operator

Prometheus

Grafana

AlertManager

node-exporter

kube-state-metrics

8.1. 为什么需要 Operator？

传统：

修改：

prometheus.yml

很麻烦。

Kubernetes：

使用 CRD：

例如：

ServiceMonitor

PodMonitor

PrometheusRule

例如：

ServiceMonitor：

告诉 Prometheus：

发现这个Service

抓取它的/metrics

9. PromQL

PromQL 是 Prometheus 查询语言。

类似：

SQL + 时间序列。

9.1. 查询指标

CPU：

node_cpu_seconds_total

9.2. 过滤

指定节点：

node_cpu_seconds_total{
instance="node01"
}

9.3. 聚合

平均：

avg(cpu_usage)

9.4. 求和

sum(container_memory_usage_bytes)

9.5. 时间函数

增长速度：

rate(
http_requests_total[5m]
)

9.6. Kubernetes 案例

Pod重启：

kube_pod_container_status_restarts_total

找异常：

increase(
kube_pod_container_status_restarts_total[1h]
)

表示：

过去1小时增加多少次重启。

10. Prometheus 在 AIOps 中的作用

这是你最关心的部分。

Prometheus负责：

感知系统状态。

但是它不会：

判断原因
自动决策

AIOps：

Prometheus

    |

指标数据

    |

Python/Pandas

    |

特征工程

    |

ML模型

    |

LLM Agent

    |

自动操作

例如：

Prometheus:

发现：

mysql_replication_lag
=30s

但是AI需要：

过去1小时：

延迟持续增长

IO wait增加

CPU稳定

最近发布版本

所以：

Python处理：

生成：

{
"service":"mysql",

"risk":"high",

"reason":[
"replication lag increasing",
"disk latency rising"
]
}

然后：

Agent：

执行：

禁止调度新实例

11. Prometheus 局限性

非常重要。

Prometheus 不适合：

11.1. 大量日志

例如：

一天10TB日志

应该用：

Loki
Elasticsearch

11.2. 长期海量存储

Prometheus本地存储：

通常：

几周到几个月。

长期：

使用：

Thanos
Cortex
VictoriaMetrics

11.3. 不负责链路追踪

Trace：

使用：

Jaeger
Tempo

12. 运维工程师需要掌握的程度

目标：

AIOps/SRE

建议：

12.1. 必须掌握

⭐⭐⭐⭐⭐

Prometheus架构
Exporter
Metric类型
PromQL
ServiceMonitor
Alert规则
Grafana

12.2. 进一步

⭐⭐⭐⭐

自定义Exporter
Python调用API
指标设计
Histogram/P99
Thanos

12.3. 高级

⭐⭐⭐

Prometheus源码
TSDB原理
Remote Write
高可用部署

13. 学习路线总结

典型学习链路：

Linux

 ↓

Kubernetes

 ↓

Prometheus

 ↓

Python requests

 ↓

Pandas/Numpy

 ↓

异常检测

 ↓

AIOps Agent

Prometheus 是中间非常关键的一层。

它相当于：

AIOps 的感知神经系统。

没有 Prometheus，Agent 不知道系统发生了什么；没有数据处理，Agent 不知道这些数据意味着什么；没有 Agent，Prometheus 只能告诉你“哪里红了”。

MySQL 资源池调度场景属于典型的：

Prometheus负责采集 → Python负责理解 → Agent负责决策。

YancheBlog

热门标签