普罗米修斯笔记：初识Prometheus

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实现，例如：

范围	常用Exporter
数据库	MySQL Exporter, Redis Exporter, MongoDB Exporter, MSSQL Exporter等
硬件	Apcupsd Exporter，IoT Edison Exporter， IPMI Exporter, Node Exporter等
消息队列	Beanstalkd Exporter, Kafka Exporter, NSQ Exporter, RabbitMQ Exporter等
存储	Ceph Exporter, Gluster Exporter, HDFS Exporter, ScaleIO Exporter等
HTTP服务	Apache Exporter, HAProxy Exporter, Nginx Exporter等
API服务	AWS ECS Exporter， Docker Cloud Exporter, Docker Hub Exporter, GitHub Exporter等
日志	Fluentd Exporter, Grok Exporter等
监控系统	Collectd Exporter, Graphite Exporter, InfluxDB Exporter, Nagios Exporter, SNMP Exporter等
其它	Blockbox Exporter, JIRA Exporter, Jenkins Exporter， Confluence 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 配置选项。