Prometheus监控数据格式

1、Prometheus metrics的概念
2、k/v的数据形式
3、Prometheus exporter的使用（pull形式采集数据）
4、Prometheus pushgateway的入门介绍（push形式采集数据）

Prometheus监控中，对于采集过来的数据，统一称为metrics数据
Metrics，熟悉大数据系统的不可能没听过说过metrics，当我们需要为某个系统某个服务做监控、做统计，就需要用到Metrics。
Metrics是一种采样数据的总称（metrics并不代表某一种具体的数据格式，是一种对于度量计算单位的抽象）

metrics的几种主要的类型

Gauges

最简单的度量指标，只有一个简单的返回值，或者叫瞬时状态，例如，我们想衡量一个的处理队列中任务的个数用更简单的方式举个例子
例如：如果我要监控硬盘容量或者内存的使用量，那么就应该使用Gauges的metrics格式来度量
因为硬盘的容量或者内存的使用量是随着时间的推移不断的瞬时 没有规则的 变化
这种变化没有规律，当前是多少，采集回来就是多少
既不能肯定是 一直持续增长，也不能肯定是一直降低
是多少就是多少，这种就是Gauges使用类型的代表
如图所示CPU的上下浮动就是采集使用Gauge形式的 metrics数据 没有规律

Counters类型metrics

Counter就是计数器，从数据量0开始累计计算，在理想状态下，只能是永远的增持，不会降低（一些特殊情况另说）
举个例子来说
比如对用户访问量的采样数据
我们的产品被用户访问一次就是1过了10分钟后积累到100
过一天后积累到20000
一周后积累到100000-150000
如下图展示的。Counter数据 是从0开始，一直不断的积累，累加下去的，所以理想状态下，不可能出现任何降低的状况
最多只可能是一只保持不变（例如：用户不在访问了，那么当前累积的总访问量，会以一条水平线的状态保持下去，直到再次被访问）
如下图展示的就是一个counter类型的metrics数据采集。采集的是用户的访问累积量

Histograms

Histograms统计数据的分布情况。比如最小值，最大值，中间值，还有中位数，75百分位，90百分位，95百分位，98百分位，99百分位，和99.9百分位的值（percentiles）。
这是一种特殊的metrics数据类型，代表的是一种
近似的百分比估算数值

这个是metrics种类最难理解的一种（但是很实用）估计大多数数学员看了上面这几行定义 头会很大

介绍什么是Histogram数据

histogram类型（prometheus中，其实提供了一个基于histogram算法的函数可以直接使用）可以分别统计出全部用户的响应时间中~=0.05秒的量有多少 0~0.05秒的有多少，>2秒的有多少 >10秒的有多少=>1%

可以很清晰的看到当前系统中，处于基本正常状态的有多少百分比的用户（或者是请求）多少处于速度极快的用户，多少处于慢请求或者有问题的请求

k/v的数据形式

Prometheus的数据类型就是依赖于 metrics的类型来计算的
而对于采集回来的数据类型，必须要以一种具体的数据格式供查看和使用
看一下一个exporter采集来的服务器上的k/v形式metrics数据
当一个exporter（node_exporter）被安装和运行在被监控的服务器上后
使用简单的curl命令就可以看到exporter采集到的metrics数据的样子，以k/v的形式展现和保存 curl localhost:9100/metrics

如上图所示curl之后的结果输出
Prometheus_server
带#的行是注释行用来解释下面这一项k/v数值 是什么采样的数据
而真正关心的是数据

用空格分开KEY/Value数据
第一个代表的是当前采集的最大文件句柄数是65535
第二个代表的是当前采集的被打开的文件句柄数是10
另外 再看下这里

第二行#告诉我们了这一项数据的metrics类型属于gauge

exporter的使用

官网提供了丰富的成型exporter插件可以使用
举几个例子

pushgateway的概念介绍
exporter是首先安装在被监控服务器上运行在后台
然后自动采集系统数据，本身又是一个HTTP_server可以被Prometheus服务器 定时去HTTP GET取得数据属于pull的形式
如果把这个过程反过来
push的形式十八pushgatewat安装在客户端或者服务端（其实装哪里都无所谓）
pushgateway本身也是一个http服务器

运维通过自己的脚本程序 抓自己想要的监控数据，然后推送到pushgateway再由pushgateway推送到prometheus服务端是一个反过来的被动模式

已经有了那么强大的pull形式的node_exporter采集，为什么还需要一个pushgateway的形式呢？

1、exporter虽然采集类型已经很丰富了，但是我们依然需要很多自制的监控数据，非规则化的自定制的
2、exporter由于数据类型采集量大，其实很多数据或者说大部分数据其实我们监控中真的用不到，用pushgateway是定义一项数据就采集着一种节省资源
3、一个新的自定义的pushgateway脚本开发远远比开发一个全新的exporter简单快速的多的多！！！（exporter的开发需要使用真正的编程语言，shell这种快速脚本是不行的，而且需要了解很多Prometheus自定义的编程格式才能开始制作工作量很大）
4、exporter虽然已经很丰富了，但是依然有很多的我们需要的采集形式，exporter无法提供，或者说现有的expoter还不支持，但是如果使用pushgateway的形式就可以任意灵活想做什么都可以做到，而且极快