prometheus自定义监控指标

基础知识

1.在Prometheus官网下载组件

https://prometheus.io/download/

2.第三方插件

https://prometheus.io/docs/instrumenting/exporters/

3.客户库

https://www.kancloud.cn/cdh0805010118/prometheus/719366

4.PushGateway 文档详解

https://blog.csdn.net/aixiaoyang168/article/details/102818289

一.监控指标

在容器监控的这套系统中，prometheus是一个重要的组件，它可以完成监控指标的收集、存储以及报警，但由于prometheus自身功能不够强大，因此需要结合其他组件来构成一个完成容器监控体系。

prometheus有许多许多的第三方插件，这些插件各司其职，有各种数据库的监控插件、硬件监控插件、系统消息插件、存储插件、HTTP相关插件、容器插件、云平台插件等等许多插件。官方文档提供的第三方插件就有一百多个，这些插件的输出格式都按照prometheus的要求输出，所以你自己也可以写插件供prometheus来使用。

prometheus采集到的监控数据均以metric（指标）形式保存在时序数据库中（TSDB）

每一条时间序列由 metric 和 labels 组成，每条时间序列按照时间的先后顺序存储它的样本值。

默认情况下各监控client向外暴露一个HTTP服务，prometheus会通过pull方式获取client的数据，数据格式如下：

`#  HELP node_cpu Seconds the cpus spent in each mode.``#  TYPE node_cpu counter``node_cpu{cpu=``"cpu0"``,mode=``"idle"``}    362812.7890625``#  HELP node_load1 1m   load    average.``#  TYPE node_load1 gauge``node_load1 3.0703125`

下图横坐标代表的是时间（时间戳的方式记录在TSDB中），纵坐标代表了各种不同的指标名称，坐标系中的黑点代表了各个指标在不同时间下的值。

每一个横线就是时间序列

每个黑点就是样本（prometheus将样本以时间序列的方式保存在内存中，然后定时保存到硬盘上）

指标（metric）的格式如下：

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

指标名称反映的是监控了什么。

标签反映的是样本的维度，可以理解成指标的细化。比如：

`api_http_requests_total{method=``"POST"``,  handler=``"/messages"``}`

指标是“api_http_requests_total”，含义是通过api请求的http总数。

标签“method=“POST”” “handler=”/messages""代表了这些http请求中 POST 请求并且 handler是/messages的数量

上述指标等同于：

`{__name__=``"api_http_requests_total"``，method=``"POST"``,  handler=``"/messages"``}`

指标有四种类型

1、Counter 只增不减计数器

2、Gauge 可增可减仪表盘

3、Histogram 直方图

4、Summary 摘要型

prometheus的客户端与服务端

客户端是提供监控指标数据的一端（如写的exporter）。prometheus提供了各种语言的客户端库，需要通过Prometheus客户端库把监控的代码放在被监控的服务代码中。当Prometheus获取客户端的HTTP端点时，客户端库发送所有跟踪的度量指标数据到服务器上。
服务端是指prometheus server，拉取、存储和查询各种各种指标数据。

histogram
histogram是柱状图，在Prometheus系统中的查询语言中，有三种作用：
对每个采样点进行统计（并不是一段时间的统计），打到各个桶(bucket)中
对每个采样点值累计和(sum)
对采样点的次数累计和(count)
度量指标名称: [basename]的柱状图, 上面三类的作用度量指标名称

[basename]_bucket{le=“上边界”}, 这个值为小于等于上边界的所有采样点数量
[basename]_sum
[basename]_count

summary
因为histogram在客户端就是简单的分桶和分桶计数，在prometheus服务端基于这么有限的数据做百分位估算，所以的确不是很准确，summary就是解决百分位准确的问题而来的。summary直接存储了 quantile 数据，而不是根据统计区间计算出来的。
Prometheus的分为数称为quantile，其实叫percentile更准确。百分位数是指小于某个特定数值的采样点达到一定的百分比

summary是采样点分位图统计。它也有三种作用：
在客户端对于一段时间内（默认是10分钟）的每个采样点进行统计，并形成分位图。（如：正态分布一样，统计低于60分不及格的同学比例，统计低于80分的同学比例，统计低于95分的同学比例）
统计班上所有同学的总成绩(sum)
统计班上同学的考试总人数(count)
带有度量指标的[basename]的summary 在抓取时间序列数据展示。

观察时间的φ-quantiles (0 ≤ φ ≤ 1), 显示为[basename]{分位数="[φ]"}
[basename]_sum，是指所有观察值的总和
[basename]_count, 是指已观察到的事件计数值
summary对quantile的计算是依赖第三方库perk实现的：
github.com/beorn7/perks/quantile

查看分位数时summary和histogram的选择

清楚几点限制：

Summary 结构有频繁的全局锁操作，对高并发程序性能存在一定影响。histogram仅仅是给每个桶做一个原子变量的计数就可以了，而summary要每次执行算法计算出最新的X分位value是多少，算法需要并发保护。会占用客户端的cpu和内存。
不能对Summary产生的quantile值进行aggregation运算（例如sum, avg等）。例如有两个实例同时运行，都对外提供服务，分别统计各自的响应时间。最后分别计算出的0.5-quantile的值为60和80，这时如果简单的求平均(60+80)/2，认为是总体的0.5-quantile值，那么就错了。
summary的百分位是提前在客户端里指定的，在服务端观测指标数据时不能获取未指定的分为数。而histogram则可以通过promql随便指定，虽然计算的不如summary准确，但带来了灵活性。
histogram不能得到精确的分为数，设置的bucket不合理的话，误差会非常大。会消耗服务端的计算资源。

一、PushGateway

grafana结合prometheus提供了大量的模板，虽然这些模板几乎监控到了常见的监控指标，但是有些特殊的指标还是没能提供（也可能是我没找到指标名称）。受zabbix的影响，自然而然想到了自定义监控项，promethues同样也支持。

Pushgateway是prometheus的一个重要组件，利用该组件可以实现自动以监控指标，从字面意思来看，该部件不是将数据push到prometheus，而是作为一个中间组件收集外部push来的数据指标，prometheus会定时从pushgateway上pull数据。

pushgateway并不是将Prometheus的pull改成了push，它只是允许用户向他推送指标信息，并记录。而Prometheus每次从 pushgateway拉取的数据并不是期间用户推送上来的所有数据，而是client端最后一次push上来的数据。因此需设置client端向pushgateway端push数据的时间小于等于prometheus去pull数据的时间，这样一来可以保证prometheus的数据是最新的。

**【注意】**如果client一直没有推送新的指标到pushgateway，那么Prometheus获取到的数据是client最后一次push的数据，直到指标消失（默认5分钟）。
Prometheus本身是不会存储指标的，但是为了防止pushgateway意外重启、工作异常等情况的发送，在pushgateway处允许指标暂存，参数–persistence.interval=5m，默认保存5分钟，5分钟后，本地存储的指标会删除。

使用pushgateway的理由：
1、prometheus默认采用pull模式，由于不在一个网络或者防火墙的问题，导致prometheus 无法拉取各个节点的数据。
2、监控业务数据时，需要将不同数据汇总，然后由prometheus统一收集

pushgateway的缺陷：
1、多个节点的数据汇总到pushgateway，当它宕机后影响很大
2、pushgateway可以持续化推送所有的监控数据，即使监控已经下线，还会获取旧的监控数据。需手动清理不需要的数据
3、重启后数据丢失

二进制包安装
二进制包安装方式，直接从官方 Github 下载最新二进制安装包，解压即可。

$ wget https://github.com/prometheus/pushgateway/releases/download/v1.0.0/pushgateway-1.0.0.linux-amd64.tar.gz
$ tar xzvf pushgateway-1.0.0.linux-amd64.tar.gz 
$ mv pushgateway-1.0.0.linux-amd64 /usr/local/pushgateway

使用命令 ./pushgateway 命令即可启动服务，此时浏览器访问 http://:9091 即可访问 UI 页面，只不过默认 Metrics 上没有任何数据展示，那是因为我们还没有往 PushGateway 上推送任何数据。

PushGateway 服务启动完毕，但是还没有跟 Prometheus 关联起来，我们需要的是通过 PushGateway 来上传自定义监控数据，然后通过 Prometheus 采集这些数据来进行监控。那么就需要将 PushGateway 添加到 Prometheus 目标任务中去，增加 prometheus.yml 配置如下：

job_name: 'pushgateway'
static_configs:

- targets: ['172.30.12.167:9091']
  labels:
    instance: pushgateway

说明一下，这里采用 static_configs 静态配置方式，因为目前就一个 PushGateway，如果有多个可以考虑其他服务发现方式，来方便动态加载，具体可以参考这里。配置完毕后，重启 Prometheus 服务，此时可以通过 Prometheus UI 页面的 Targets 下查看是否配置成功。

prometheus-pushgateway

API 方式 Push 数据到 PushGateway
接下来，我们要 Push 数据到 PushGateway 中，可以通过其提供的 API 标准接口来添加，默认 URL 地址为：http://:9091/metrics/job/{/<LABEL_NAME>/<LABEL_VALUE>}，其中是必填项，为 job 标签值，后边可以跟任意数量的标签对，一般我们会添加一个 instance/<INSTANCE_NAME> 实例名称标签，来方便区分各个指标。

接下来，可以 Push 一个简单的指标数据到 PushGateway 中测试一下。

$ echo "test_metric 123456" | curl --data-binary @- http://172.30.12.167:9091/metrics/job/test_job

执行完毕，刷新一下 PushGateway UI 页面，此时就能看到刚添加的 test_metric 指标数据了。

curl发送形式说明

据到 PushGateway 中测试一下。

$ echo "test_metric 123456" | curl --data-binary @- http://172.30.12.167:9091/metrics/job/test_job

执行完毕，刷新一下 PushGateway UI 页面，此时就能看到刚添加的 test_metric 指标数据了。

curl发送形式说明

–data-binary 与-d, --data类似，如果以@开头，则后面必须跟着文件名，并且文件中的换行符，回车符会保留，也不会做将要发送的数据写入文件“名字”，作用是将文件中的数据发送到指定地方

原文链接：https://blog.csdn.net/weixin_35688430/article/details/118416312