Prometheus监控指标的label注入方法

Posted yaodd

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Prometheus监控指标的label注入方法相关的知识,希望对你有一定的参考价值。

Prometheus采集监控指标的方式如下图所示,Prometheus Server经过一定的配置可以从各种Exporter主动采集监控数据。广义上的Exporter可以是任何以Prometheus标准暴露监控指标的进程。不过严格来说可以划分为以下两类:

 
1. 对于Etcd这类应用程序,它们在代码中利用Prometheus官方提供的SDK定义了一系列自定义指标供Prometheus Server采集,此类指标一般用于描述该程序自身的运行状况。一般对于新开发或者改动难度较小的程序,可以用这种对代码侵入性较大的方式暴露指标。
 
2. 标准意义上的Expoerter本质上就是指标的转换层,例如Prometheus社区提供了一个名为Node Exporter的组件,该组件的作用为采集节点的CPU,内存等指标并转换以符合Prometheus标准的格式暴露出去。一般对于代码改动难度较大或已经有成熟的指标暴露机制的程序,这种方式是较为合适的。

技术图片
 
Prometheus Server采集指标的方式,本质上是向Exporter发送一个HTTP请求并获取该Exporter定义的所有指标内容,例如对于Node Expoerter的采集形式如下:
 
# curl http://192.168.0.6:9100/metrics
# HELP node_network_transmit_bytes_total Network device statistic transmit_bytes.
# TYPE node_network_transmit_bytes_total counter
node_network_transmit_bytes_total{device="eth0"} 2.74314960472e+11
node_network_transmit_bytes_total{device="lo"} 7.248889467e+09
# HELP node_boot_time_seconds Node boot time, in unixtime.
# TYPE node_boot_time_seconds gauge
node_boot_time_seconds 1.574417622e+09
...

  

从上述示例可以看到,一次抓取过程返回的内容本质上是纯文本,我们截取了其中的两个指标,`node_network_transmit_bytes_total`和`node_boot_time_seconds`分别表示节点上各个网卡发送的数据的字节数以及节点的启动时间。对于`node_network_transmit_bytes_total`包含一个key为`device`的label用于区分各个网卡,而`node_boot_time_seconds`并不包含任何指标。
 
事实上,指标中包含的label能够让我们从更多维度更好地对指标进行操作。但是很多时候,Exporter指标中原生定义的label是不足以满足我们的需求的。例如,对于Node Exporter暴露的指标中显然没有包含组织信息的label,但是如果有这么一个label存在,加上Prometheus强大的PromQL查询语句,我们能够很容易地从组织维度对指标进行划分。
 
那么如何在Exporter暴露的指标中添加额外的label呢?最直接的方式当然是侵入式地修改Exporter的源码,从而在源头加上这些“定制化”的labels。当然,这种方式对于一些简单的自研组件是可行的。但是对于Node Exporter以及nginx Exporter等较为复杂的Exporter直接修改源码并不是那么地简单,而且假如我要为所有指标加上一个公共的label,那么也就意味着要修改所有Exporter的源码。
 
显然,我们需要一种更为通用的方式,从上文的分析可知,标准意义的Exporter本质上是一个中间层,用于指标的转换。那么我们是否可以再加一个中间层,用于自定义label的添加呢?架构如下:
 
技术图片
 
在Prometheus Server和Exporter之间构建一个中间组件Adapter,此时Prometheus不再直接向Exporter发起HTTP请求抓取监控指标,而是向Adapter发起请求。一旦Adapter接收到请求之后会转而向Exporter发起请求真正抓取到监控指标。已知指标内容其实就是一些文本,因此只要做一些简单的插入操作就能将自定义的指标注入。最后,将处理后的内容再返回至Prometheus Server即可。若Adapter注入的指标为{org="dev"},那么经过Adapter处理之后,Prometheus Server真正抓取到的指标如下:
 
# curl http://192.168.0.6:9100/metrics
# HELP node_network_transmit_bytes_total Network device statistic transmit_bytes.
# TYPE node_network_transmit_bytes_total counter
node_network_transmit_bytes_total{device="eth0", org="dev"} 2.74314960472e+11
node_network_transmit_bytes_total{device="lo", org="dev"} 7.248889467e+09
# HELP node_boot_time_seconds Node boot time, in unixtime.
# TYPE node_boot_time_seconds gauge
node_boot_time_seconds{org="dev"} 1.574417622e+09
...

  

通常在Kubernetes环境下,我们会将Adapter以Sidecar的形式部署在Exporter所在的Pod中,如果能够将Adapter需要注入的指标值从配置文件中读取并支持动态加载机制,那么我们就能非常灵活地为任意Exporter的指标加入任意的定制化label。

以上是关于Prometheus监控指标的label注入方法的主要内容,如果未能解决你的问题,请参考以下文章

Prometheus监控的最佳实践——关于监控的3项关键指标

Prometheus监控的最佳实践——关于监控的3项关键指标

prometheus能监控哪些指标

监控利器Prometheus——Prometheus+Grafana监控SpringBoot项目业务指标监控

监控利器Prometheus——Prometheus+Grafana监控SpringBoot项目业务指标监控

监控利器Prometheus——Prometheus+Grafana监控SpringBoot项目业务指标监控