Prometheus简介

Prometheus官网地址：https://prometheus.io/

Prometheus是一套开源的监控&报警&时间序列数据库的组合,起始是由SoundCloud公司开发的。成立于2012年，之后许多公司和组织接受和采用prometheus,他们便将它独立成开源项目，并且有公司来运作.该项目有非常活跃的社区和开发人员，目前是独立的开源项目，任何公司都可以使用它，2016年，Prometheus加入了云计算基金会，成为kubernetes之后的第二个托管项目.google
SRE的书内也曾提到跟他们BorgMon监控系统相似的实现是Prometheus。现在最常见的Kubernetes容器管理系统中，通常会搭配Prometheus进行监控。

Prometheus特性

Prometheus是一个开源的系统监控和报警工具，它有以下特点：

• 自定义多维数据模型（时序列数据由metric名和一组key/value组成）
• 多维度上灵活的查询语言（PromQI）
• 不依赖分布式存储，支持单主节点工作
• 通过基于HTTP的pull方式采集时序数据
• 可以通过push gateway进行时序数据推送（pushing）
• 可以通过服务发现或者静态配置取获取要采集的目标服务器
• 多种可视化图表及仪表盘支持

pull方式

Prometheus采集数据时用的pull也就是拉模型，通过HTTP协议去采集指标，只要应用系统能够提供HTTP接口就可以接入监控系统，相比于私有协议或二进制协议来说开发、简单。

push方式

对于定时任务这种短周期的指标采集，如果采用pull模式，可能造成任务结束了，Prometheus还没有来得及采集，这个时候可以使用加一个中转层，客户端推数据到push gateway缓存一下，由prometheus从push gateway pull指标过来。（需要额外搭建push gateway，同事需要新增job去从gateway采数据）

核心组成部分

Prometheus server

主要负责数据采集和存储，并提供PromQL查询语言支持。Prometheus server本身就是一个实时数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘中。

Client libraries

丰富的客户端sdk，官方提供的客户端类库有go、java、scala、python、ruby，其他还有很多第三方类库，支持nodejs、php、erlang等。

Push Gateway

支持临时性Job主动推送指标的中间网关。主要用于短期的jobs。由于这类jobs存在时间较短，可能在Prometheus来pull之前就消失了。为此，这次jobs可以直接向Prometheus中间网关推送他们的metrics。这种方式主要用于服务层面的metrics，对于机器层面的metrices，需要使用node exporter。

Exporters

支持其他数据源的指标导入到Prometheus，支持数据库、硬件、消息中间件、存储系统、HTTP服务器、jmx等。
Exporter将监控数据采集的端点通过HTTP服务形式暴露给Prometheus Server，将其转化为Prometheus支持的格式，Prometheus Server通过访问该Exporter提供的Endpoint端点，即可以获取到需要采集的监控数据。可以将exporter分成2类：
直接采集：这一类exporter直接内置了对Prometheus监控支持，比如cAdvisor、Kubernetes、Etcd、Gokit等，都直接内置了用于向Prometheus暴露监控数据的端点。
间接采集：原有监控目标并不直接支持Prometheus，因此需要通过Prometheus提供的Client Library编写该监控目标的监控采集程序。目前其生态中已经有很多exporter实现，例如：

Alertmanager

一个警告控制组件用来控制警告。在Prometheus中支持基于PromQL创建告警规则，如果满足PromQL定义的规则，则会产生一条告警。当AlertManager从Prometheus server端接收到alerts后，会进行去除重复数据，分组，并路由到对端接收方式，发出报警。常见的接收方式有：电子邮件，pargerduty，webhook等。

大部分的Prometheus组件是用Go语言编写的，他们很易于以二进制文件方式构建和部署。

架构图

数据可以通过直接jobs或者通过push gateway方式抽取样本指标。它将所有抽取的样本存储在本地，并对这些数据运行规则，从现有数据中聚合和记录新的时间学列，或者生成告警。可以使用Grafana或者其他API使用者来可视化收集的数据。

Prometheus工作流程

1、Prometheus server定期从配置好的jobs或者exporters中拉取metrics，或者从push gateway拉取metrics，或者从其他的Prometheus server中拉取metrics
2、Prometheus server在本地存储收集的metrics，并运行定义好的alert.rules，通过一定规则进行清理和整理数据，并把得到的结果存储到新的时间序列中。记录新的时间序列或者向Alertmanager推送警报。
3、Prometheus通过PromQL和其他可视化的展现收集的数据。Prometheus支持很多方式的图表可视化，例如Grafana、自带的Promdash以及自身提供的模板引擎等等。Promenade还提供HTTP API的查询方式，自定义所需要的输出。

Prometheus数据模型

Prometheus 从根本上所有的存储都是按时间序列去实现的，相同的 metrics(指标名称) 和 label(一个或多个标签) 组成一条时间序列，不同的label表示不同的时间序列。为了支持一些查询，有时还会临时产生一些时间序列存储。
Prometheus数据格式与OpenTSDB相似：

<metric name>{<label name>=<label value>, ...}

指标名称

一般是给监测对像起一名字，例如 http_requests_total 这样，它有一些命名规则，可以包字母数字之类的的。通常是以应用名称开头监测对像数值类型单位这样。例如：

 http_requests_total 

标签

就是对一条时间序列不同维度的识别了，例如 一个http请求用的是POST还是GET，它的endpoint是什么，这时候就要用标签去标记了。最终形成的标识便是这样了：

http_requests_total{method="POST",endpoint="/api/tracks"}

时序样本

按照某个时序以时间维度采集的数据据，称之为样本，其值包含：

• 一个float64值
• 一个毫秒级的unix时间戳

Prometheus随时间采集监控数据点，每个数据点都是时间戳和值的元组。出于监控的目的，时间戳是一个整数，值是任意数字–64位浮点数对于Counter和Gauge类型来说都是一个很好的表示方式。按时间戳严格单调递增的数据点序列是一个由标识符寻址的Series。标识符是带有标签维度的监控项名称，标签维度划分单个监控项的度量空间**，每个监控项名称加上一组唯一标签是其自己的时间序列**，其具有与之关联的值流。

## series格式为 identifier -> (t0, v0), (t1, v1), (t2, v2), (t3, v3), ....
## 一组典型的系列标识符，是请求技术监控度量的一部分
requests_total{path="/status", method="GET", instance=”10.0.0.1:80”}
requests_total{path="/status", method="POST", instance=”10.0.0.3:80”}
requests_total{path="/", method="GET", instance=”10.0.0.2:80”}
## 简化表示，监控项名称可以是另一个标签维度__name__,在查询是它可能会被特殊处理，但与我们存储它的方式无关
{__name__="requests_total", path="/status", method="GET", instance=”10.0.0.1:80”}
{__name__="requests_total", path="/status", method="POST", instance=”10.0.0.3:80”}
{__name__="requests_total", path="/", method="GET", instance=”10.0.0.2:80”}
因此，identifier 形如 metricName{label1=value1,label2=value2,...} 或 
{__name__="metricName",label1=value1,label2=value2,...}
## 在简化的视图中，所有数据点可以在二维平面上展开。水平维度表示时间，垂直维度按series展开
series
 ^ 
 │ . . . . . . . . . . . . . . . . . . . . . . {__name__="request_total", method="GET"}
 │ . . . . . . . . . . . . . . . . . . . . . . {__name__="request_total", method="POST"}
 │ . . . . . . .
 │ . . . . . . . . . . . . . . . . . . . ... 
 │ . . . . . . . . . . . . . . . . . . . . . 
 │ . . . . . . . . . . . . . . . . . . . . . {__name__="errors_total", method="POST"}
 │ . . . . . . . . . . . . . . . . . {__name__="errors_total", method="GET"}
 │ . . . . . . . . . . . . . .
 │ . . . . . . . . . . . . . . . . . . . ... 
 │ . . . . . . . . . . . . . . . . . . . . 
 v
 <-------------------- time --------------------->

Prometheus 的四种数据类型

Counter(计数器)

• Counter 用于累计值，例如 记录 请求次数、任务完成数、错误发生次数。
• 一直增加，不会减少。
• 重启进程后，会被重置。

  例如：http_response_total{method="GET",endpoint="/api/tracks"} 10
  10秒后抓取 http_response_total{method="GET",endpoint="/api/tracks"} 100

Gauge(仪表盘)

• Gauge 常规数值，例如 温度变化、CPU,内存,网络使用变化。
• 可变大，可变小。
• 重启进程后，会被重置

  例如： memory_usage_bytes{host="master-01"} 100 < 抓取值
  memory_usage_bytes{host="master-01"} 30
  memory_usage_bytes{host="master-01"} 50
  memory_usage_bytes{host="master-01"} 80 < 抓取值

Histogram(直方图)

Histogram 可以理解为柱状图的意思，常用于跟踪事件发生(通常是请求持续时间或响应大小)的规模，例如：请求耗时、响应大小。它特别之处是可以对记录的内容进行分组，提供 count 和 sum 全部值的功能。

例如：{小于10=5次，小于20=1次，小于30=2次}，count=7次，sum=7次的求和值

Summary(摘要)

Summary和Histogram十分相似，常用于跟踪事件(通常是要求持续时间和响应大小)发生的规模，例如：请求耗时、响应大小。同样提供 count 和 sum 全部值的功能。

例如：count=7次，sum=7次的值求值

它提供一个quantiles的功能，可以按%比划分跟踪的结果。例如：quantile取值0.95，表示取采样值里面的95%数据

Jobs and Instances

在prometheus中，任何被采集的目标被称为instance,通常对应于单个进程，而相同类型(可扩展性和可靠性的复制)的instance集合被称为Job。例如:Api server job由4个复制instance组成:

- job: api-server
    - instance1: 1.2.3.4:5670
    - instance2: 1.2.3.4:5671
    - instance3: 5.6.7.8:5670
    - instance3: 5.6.7.8:5671

当prometheus采集目标时，它会自动附加某些标签，用于识别被采集的目标。
job： 配置目标所属的job名称。
instance：目标 HTTP URL:部分
如果任何一个标签已经存在于采集的数据中，则此行为依赖honor_labels 配置选项。