众所周知，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 <name> <descriptions> - go_gc_duration_seconds ...
- 集合名字 - TYPE <name> <type> - go_gc_duration_seconds summary <summary>
具体细节详见官方文档-教你写Client、官方文档-数据模型、官方文档-指标类型、官方文档-推荐指标输出格式。另外，可以参考这个博客开始简单的例子。
总之，每个程序按照格式，以Web服务的形式暴露自己的指标，Prometheus就可以抓取啦。
Prometheus的基本结构
Prometheus运行的基本结构如下图1所示。
- 指标数据在业务提供的服务上以Web服务的形式暴露出来，由配置文件和服务发现机制通知Prometheus去指定位置抓取数据。
- Prometheus抓取指标后，搬运到本地(PromuTSDB)、远程仓库(OpenTSDB、InfluxDB...)
- 其他消费者，包括Grafana、Prometheus的自身的Web服务，从时间序列数据库中取数据
所以，实际上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容量
- 工人取一块砖平均要多久？ - 取数据延迟
- 工人送一块砖到仓库要多久? - 存数据网络延迟
- 仓库能放多少砖? - 数据库容量
- 工人搬砖的时候，会不会把路占了，让别人走不了？- 占用网络带宽
敬请期待。
