Prometheus介绍

Prometheus

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

特性

prometheus的主要特点

自定义多维数据模型(时序列数据由metric名和一组key/value标签组成)
非常高效的存储平均一个采样数据占 ~3.5 bytes左右，320万的时间序列，每30秒采样，保持60天，消耗磁盘大概228G。
在多维度上灵活且强大的查询语言(PromQl)
不依赖分布式存储，支持单主节点工作
通过基于HTTP的pull方式采集时序数据
可以通过push gateway进行时序列数据推送(pushing)
可以通过服务发现或者静态配置去获取要采集的目标服务器
多种可视化图表及仪表盘支持

pull方式

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

push方式

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

prometheus适用于监控所有时间序列的项目

目前其生态中已经有很多exporter实现，例如：

Node/system metrics exporter
AWS CloudWatch exporter
Blackbox exporter
Collectd exporter
Consul exporter
Graphite exporter
HAProxy exporter
InfluxDB exporter
JMX exporter
Memcached exporter
Mesos task exporter
MySQL server exporter
SNMP exporter
StatsD exporter

组成及架构

Prometheus生态系统由多个组件组成。其中许多组件都是可选的

Prometheus server

主要负责数据采集和存储，提供PromQL查询语言的支持
客户端sdk官方提供的客户端类库：

go、java、scala、python、ruby，其他还有很多第三方开发的类库，支持nodejs、php、erlang等
Push Gateway

支持临时性Job主动推送指标的中间网关
PromDash

使用rails开发的dashboard，用于可视化指标数据
exporters

支持其他数据源的指标导入到Prometheus，支持数据库、硬件、消息中间件、存储系统、http服务器、jmx等
alertmanager

实验性组件、用来进行报警
prometheus_cli

命令行工具
其他辅助性工具

prometheus大多数组件都是用Go编写的，他们可以非常轻松的基于二进制文件部署和构建

它的服务过程是这样的 Prometheus Server 负责定时去目标上抓取 metrics(指标) 数据，每个抓取目标需要暴露一个http服务的接口给它定时抓取。
Prometheus支持通过配置文件、kubernetes、zookeeper、Consul、DNS SRV lookup等方式指定抓取目标。
Alertmanager 是独立于Prometheus的一个组件，可以支持Prometheus的查询语句编写规则，提供十分灵活的报警方式。
Prometheus支持很多方式的图表可视化，例如十分精美的Grafana，自带的Promdash，以及自身提供的模版引擎等等，还提供HTTP API的查询方式，自定义所需要的输出。
PushGateway这个组件是支持Client主动推送 metrics 到PushGateway，而Prometheus只是定时去Gateway上抓取数据。

如果有使用过statsd的用户，则会觉得这十分相似，只是statsd是直接发送给服务器端，而Prometheus主要还是靠进程主动去抓取。

概念

Prometheus 的数据模型

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

metrics name & label 指标名称和标签

每条时间序列是由唯一的指标名称和一组标签（key=value）的形式组成。

指标名称

一般是给监测对像起一名字，例如 http_requests_total 这样，它有一些命名规则，可以包字母数字之类的的。通常是以应用名称开头监测对像数值类型单位这样。例如：
```
  - push_total
  - userlogin_mysql_duration_seconds
  - app_memory_usage_bytes
```
标签
就是对一条时间序列不同维度的识别了，例如一个http请求用的是POST还是GET，它的endpoint是什么，这时候就要用标签去标记了。最终形成的标识便是这样了
```
  http_requests_total{method="POST",endpoint="/api/tracks"}
```

记住，针对http_requests_total这个metrics name 无论是增加标签还是删除标签都会形成一条新的时间序列。
查询语句就可以跟据上面标签的组合来查询聚合结果了。
如果以传统数据库的理解来看这条语句，则可以考虑 http_requests_total是表名，标签是字段，而timestamp是主键，还有一个float64字段是值了。（Prometheus里面所有值都是按float64存储）

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 配置选项。

对于每个被采集的instance,prometheus存储如下的时间序列样本：

up{job="",instance=""}:1 如果实例处于health，为1，否则为0
scrape_duration_seconds{job="",instance=""} 持续采集时间

“up”时间序列metric对于instance可用性监控是有效的。