Prometheus 性能实验报告 - 序言（一）

众所周知，Prometheus从CNCF毕业后，已经成为运维砖工喜爱的系统监控框架。

由于本公司的砖工之前都没有用过Prometheus，使用的是比Prometheus更挫的Falcon。在大范围使用Prometheus之前，需要对Prometheus的基本性能简单测试，获得一些数据用于估算Scalability和Capacity。

(本文所述，"砖"即"监控数据"；“工人”即"Prometheus"；"路"即"网络信道")

Prometheus的角色分配如下:

• 搬砖工人: Prometheus
• 砖厂: 任意程序 (业务程序、Kubelet、ElasticSearch...)
• 砖: 各个程序提供的、符合Prometheus格式的数据接口
• 仓库: 时间序列数据库 (PromuTSDB、OpenTSDB、InfluxDB...)
• 监工: 管理搬砖工人的工具
• 消费者: 读数据的 (Grafana、Kabana...)

Prometheus是标准的数据搬运系统。数据搬运系统即字面的意思，Prometheus不产生数据，只从系统各处搬运数据到数据库。

我们先看一下"砖"是什么样子的。

(以下指标数据都是由业务程序提供的)

下面是一个Prometheus指标的例子：

container_cpu_usage_seconds_total{container_name="abc",cpu="total",id="123",name="def"} 4751.708280444

以上述指标为例，Promethues指标由如下基本部分组成：

• 指标名字 - metric name - container_cpu_usage_seconds_total
• 值 - sampling value(float64) - 4751.708280444
• 标签 - label name, value - container_name="abc"...
• 时间戳 - timestamp (Prometheus维护)

也可以定义一个“指标的集合”，如下所示

# HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 0
go_gc_duration_seconds{quantile="0.25"} 0
...

以下部分组成“指标的集合”:

• 说明 - HELP - go_gc_duration_seconds ...
• 集合名字 - TYPE - go_gc_duration_seconds summary

具体细节详见官方文档-教你写Client、官方文档-数据模型、官方文档-指标类型、官方文档-推荐指标输出格式。另外，可以参考这个博客开始简单的例子。

总之，每个程序按照格式，以Web服务的形式暴露自己的指标，Prometheus就可以抓取啦。

---

Prometheus的基本结构

Prometheus运行的基本结构如下图1所示。

图1 Prometheus官方架构图

• 指标数据在业务提供的服务上以Web服务的形式暴露出来，由配置文件和服务发现机制通知Prometheus去指定位置抓取数据。
• Prometheus抓取指标后，搬运到本地(PromuTSDB)、远程仓库(OpenTSDB、InfluxDB...)
• 其他消费者，包括Grafana、Prometheus的自身的Web服务，从时间序列数据库中取数据

所以，实际上Prometheus真正的架构应该是这样子的。

图2 Prometheus实际架构图

作为一个搬砖工人，Prometheus需要知道如下信息。

• 砖在哪? - 配置文件、服务发现组件提供地址
• 怎么搬? - Prometheus Query配置
• 搬哪去? - 数据存储配置

砖在哪?
根据配置文件和服务发现组件，Prometheus会生成一些Target。Prometheus会定期访问这些Target。

怎么搬?
如果单个Prometheus不能支持足够大的数据搬运量，可以开发简单的管理程序，进行target对应的配置文件分片，则很容易横向拓展。

在2.0版本之前，除了搬运文本数据外，还支持搬运Protobuf类型的数据（现不支持）
获取访问Target的HTTP Body，并在解析之后，存储到数据库中。

搬哪去?
Prometheus默认提供了PromuTSDB，数据以压缩文件的形式存储在本地。但在Prometheus抓取目标增多时，本地磁盘显然是存不下这么多数据的，因此Prometheus提供了Remote Storage接口。

根据Remote Storage接口，用户可以使用自己维护的后端存储，如OpenTSDB、InfluxDB、PostgreSQL，存储指标数据。在使用过程中，用户需要自己实现一个Remote Storage Adapter。

这个Adapter提供转发功能，包括Remote Read和Remote Write。(允许只实现一种)

• Remote Write: Prometheus发送规定格式的数据给Adapter，Adapter转义后发送给数据库。
• Remote Read: Prometheus规定Adapter需要解析四种运算符 "=","!=","=~","!~"。 用户在界面上查询时，Prometheus发送查询命令给Adapter，Adapter转义后发送给数据库。

为了保证充分评估Prometheus的性能，我们可以按照这个图2思路，逐个对每条路径、组件开展性能实验，估算出系统的性能瓶颈。

在接下来的文章里，我们会提供详细的Prometheus性能实验报告及代码，讨论如下问题

• 每个工人能搬多少砖? - 单个Prometheus容量
• 工人取一块砖平均要多久？ - 取数据延迟
• 工人送一块砖到仓库要多久? - 存数据网络延迟
• 仓库能放多少砖? - 数据库容量
• 工人搬砖的时候，会不会把路占了，让别人走不了？- 占用网络带宽

敬请期待。