普罗米修斯的基础原理

基本组成及架构

组成

架构

其大概的工作流程是：

1. Prometheus server 会定期从配置好的 exporters 或 jobs 中拉 metrics，或者接收来自 Pushgateway 发过来的 metrics，或者从其他的 Prometheus server 中拉 metrics。
2. Prometheus server 会在本地存储收集到的 metrics，并运行已定义好的 alert.rules，记录新的时间序列或者向 Alertmanager 推送警报。
3. Alertmanager 会根据配置文件，对接收到的警报进行处理，发出告警。
4. 在图形界面中，可视化采集数据。

主要特点

强大的多维度数据模型

1. 时间序列数据通过 metric 名和键值对来区分。
2. 所有的 metrics 都可以设置任意的多维标签。
3. 数据模型更随意，不需要刻意设置为以点分隔的字符串。
4. 可以对数据模型进行聚合，切割和切片操作。
5. 支持双精度浮点类型，标签可以设为全 unicode。

灵活而强大的查询语句（PromQL）

在同一个查询语句，可以对多个 metrics 进行乘法、加法、连接、取分数位等操作。

易于管理

Prometheus server 是一个单独的二进制文件，可直接在本地工作，不依赖于分布式存储。

高效

平均每个采样点仅占 3.5 bytes，且一个 Prometheus server 可以处理数百万的 metrics。

其它

1. 使用 pull 模式采集时间序列数据，这样不仅有利于本机测试而且可以避免有问题的服务器推送坏的 metrics。
2. 可以采用 push gateway 的方式把时间序列数据推送至 Prometheus server 端。
3. 可以通过服务发现或者静态配置去获取监控的 targets。
4. 有多种可视化图形界面。
5. 易于伸缩等等。

数字模型

Prometheus 中存储的数据为时间序列，是由 metric 的名字和一系列的标签（键值对）唯一标识的，不同的标签则代表不同的时间序列。

metric 名字：该名字应该具有语义，一般用于表示 metric 的功能，例如：http_requests_total, 表示 http 请求的总数。其中，metric 名字由 ASCII 字符，数字，下划线，以及冒号组成，且必须满足正则表达式 [a-zA-Z:][a-zA-Z0-9_:]*。

标签：使同一个时间序列有了不同维度的识别。例如 http_requests_total{method=”Get”} 表示所有 http 请求中的 Get 请求。当 method=”post” 时，则为新的一个 metric。标签中的键由 ASCII 字符，数字，以及下划线组成，且必须满足正则表达式 [a-zA-Z:][a-zA-Z0-9_:]*。

样本：实际的时间序列，每个序列包括一个 float64 的值和一个毫秒级的时间戳。

格式：{=,…}，例如：http_requests_total{method=”POST”,endpoint=”/api/tracks”}。

metric是什么？

metric（度量、指标）一个很重要的概念，在官方出现的非常高频，其本质是指存在于数据库的一条记录。

监控服务将监控数据存入数据库的某条记录时，这条记录能动态增加字段，得到通用的metric数据类型，另外还有name，label【与tag{}同义，（将额外需要扩展增加的数据生成json存入label{}，能方便的扩展字段，不用每次修改数据库表结构）】，value以及timestamp。

上述总结源自阅读: 《Prometheus 是一套开源的系统监控报警框架》.