简言

这篇文章介绍一下Prometheus中Exporter的概念和常见的类型与使用方法。

Exporter是什么

为Prometheus提供监控数据源的应用都可以被成为Exporter,比如Node Exporter则用来提供节点相关的资源使用状况,而Prometheus从这些不同的Exporter中获取监控数据,然后可以在诸如Grafana这样的可视化工具中进行结果的显示。

Exporter的一个实例可以称为Targets

Exporter的类型

  • Exporter根据来源可以分为:社区提供的Exporter和自定义的Exporter两种
  • Exporter根据支持方式可以分为:很多软件现在已经内嵌支持Prometheus,比如kubernetes或者etcd,简单来说这种类型的软件中不需要单独的Exporter用于提供给Prometheus的监控数据的功能,这是其本身的功能特性之一。当然更多的情况则是通过独立运行的Exporter来进行,比如Node Exporter,操作系统本身由于不像kubernetes那样提供对于Prometheus的支持,所以需要单独运行Node Exporter用于提供节点自身的信息给Prometheus进行监控。

社区常见的Exporter

数据库

常见的主流数据库几乎都有相应的Exporter,详细如下所示:

MongoDB exporter
MSSQL server exporter
MySQL server exporter (official)
OpenTSDB Exporter
Oracle DB Exporter
PostgreSQL exporter
Redis exporter
ElasticSearch exporter
RethinkDB exporter
Consul exporter (official)

消息队列

Kafka exporter
IBM MQ exporter
RabbitMQ exporter
RocketMQ exporter
NSQ exporter
Gearman exporter

存储

Ceph exporter
Gluster exporter
Hadoop HDFS FSImage exporter

硬件相关

Node/system metrics exporter (official)
Dell Hardware OMSA exporter
IoT Edison exporter
IBM Z HMC exporter
NVIDIA GPU exporter

问题追踪与持续集成

Bamboo exporter
Bitbucket exporter
Confluence exporter
Jenkins exporter
JIRA exporter

HTTP服务

Apache exporter
HAProxy exporter (official)
Nginx metric library
Nginx VTS exporter
Passenger exporter
Squid exporter
Tinyproxy exporter
Varnish exporter
WebDriver exporter

API服务

AWS ECS exporter
AWS Health exporter
AWS SQS exporter
Cloudflare exporter
DigitalOcean exporter
Docker Cloud exporter
Docker Hub exporter
GitHub exporter
InstaClustr exporter
Mozilla Observatory exporter
OpenWeatherMap exporter
Pagespeed exporter
Rancher exporter
Speedtest exporter
Tankerkönig API Exporter

日志

Fluentd exporter
Google’s mtail log data extractor
Grok exporter

监控系统

Akamai Cloudmonitor exporter
Alibaba Cloudmonitor exporter
AWS CloudWatch exporter (official)
Azure Monitor exporter
Cloud Foundry Firehose exporter
Collectd exporter (official)
Google Stackdriver exporter
Graphite exporter (official)
Huawei Cloudeye exporter
InfluxDB exporter (official)
JavaMelody exporter
JMX exporter (official)
Nagios / Naemon exporter
Sensu exporter
SNMP exporter (official)
TencentCloud monitor exporter
ThousandEyes exporter

其他

BIND exporter
Bitcoind exporter
cAdvisor
Dnsmasq exporter
Ethereum Client exporter
JFrog Artifactory Exporter
JMeter plugin
Kibana Exporter
kube-state-metrics
OpenStack exporter
PowerDNS exporter
Script exporter
SMTP/Maildir MDA blackbox prober
WireGuard exporter
Xen exporter

使用方式

Prometheus Server提供PromQL查询语言能力、负责数据的采集和存储等主要功能,而数据的采集主要通过周期性的从Exporter所暴露出来的HTTP服务地址(一般是/metrics)来获取监控数据。而Exporter在实际运行的时候根据其支持的方式也会分为:

  • 独立运行的Exporter应用,通过HTTP服务地址提供相应的监控数据(比如Node Exporter)

    以Node Exporter为例,由于操作系统本身并不直接支持Prometheus,同时用户也无法通过直接从操作系统层面上提供对Prometheus的支持。因此,用户只能通过独立运行一个程序的方式,通过操作系统提供的相关接口,将系统的运行状态数据转换为可供Prometheus读取的监控数据。 除了Node Exporter以外,比如MySQL Exporter、Redis Exporter等都是通过这种方式实现的。 这些Exporter程序扮演了一个中间代理人的角色。上面表中列的都是属于这种方式。

  • 内置在监控目标中,通过HTTP服务地址提供相应的监控数据(比如kubernetes)

    为了能够更好的监控系统的内部运行状态,有些开源项目如Kubernetes,ETCD等直接在代码中使用了Prometheus的Client Library,提供了对Prometheus的直接支持。这种方式打破的监控的界限,让应用程序可以直接将内部的运行状态暴露给Prometheus,适合于一些需要更多自定义监控指标需求的项目。

Exporter规范

所有的Exporter程序都需要按照Prometheus的规范,返回监控的样本数据。以Node Exporter为例,当访问/metrics地址时会返回以下内容:

1
2
3
4
5
6
# 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

这是一种基于文本的格式规范,Exporter返回的样本数据,主要由三个部分组成:样本的一般注释信息(HELP),样本的类型注释信息(TYPE)和样本。Prometheus会对Exporter响应的内容逐行解析。

如果当前行以# HELP开始,Prometheus将会按照以下规则对内容进行解析,得到当前的指标名称以及相应的说明信息:

1
# HELP <metrics_name> <doc_string>

如果当前行以# TYPE开始,Prometheus会按照以下规则对内容进行解析,得到当前的指标名称以及指标类型:

1
# TYPE <metrics_name> <metrics_type>

TYPE注释行必须出现在指标的第一个样本之前。如果没有明确的指标类型需要返回为untyped。 除了# 开头的所有行都会被视为是监控样本数据。 每一行样本需要满足以下格式规范:

1
2
3
metric_name [
"{" label_name "=" `"` label_value `"` { "," label_name "=" `"` label_value `"` } [ "," ] "}"
] value [ timestamp ]

其中metric_name和label_name必须遵循PromQL的格式规范要求。value是一个float格式的数据,timestamp的类型为int64(从1970-01-01 00:00:00以来的毫秒数),timestamp为可选默认为当前时间。具有相同metric_name的样本必须按照一个组的形式排列,并且每一行必须是唯一的指标名称和标签键值对组合。

需要特别注意的是对于histogram和summary类型的样本。需要按照以下约定返回样本数据:

1
2
3
4
5
6
7
8
9
1 . 类型为summary或者histogram的指标x,该指标所有样本的值的总和需要使用一个单独的x_sum指标表示

2 . 类型为summary或者histogram的指标x,该指标所有样本的总数需要使用一个单独的x_count指标表示。

3 . 对于类型为summary的指标x,其不同分位数quantile所代表的样本,需要使用单独的x{quantile="y"}表示。

4 . 对于类型histogram的指标x为了表示其样本的分布情况,每一个分布需要使用x_bucket{le="y"}表示,其中y为当前分布的上位数。同时必须包含一个样本x_bucket{le="+Inf"},并且其样本值必须和x_count相同。

5 . 对于histogram和summary的样本,必须按照分位数quantile和分布le的值的递增顺序排序。

以下是类型为histogram和summary的样本输出示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
以下是类型为histogram和summary的样本输出示例
# A histogram, which has a pretty complex representation in the text format:
# HELP http_request_duration_seconds A histogram of the request duration.
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.05"} 24054
http_request_duration_seconds_bucket{le="0.1"} 33444
http_request_duration_seconds_bucket{le="0.2"} 100392
http_request_duration_seconds_bucket{le="+Inf"} 144320
http_request_duration_seconds_sum 53423
http_request_duration_seconds_count 144320
# Finally a summary, which has a complex representation, too:
# HELP rpc_duration_seconds A summary of the RPC duration in seconds.
# TYPE rpc_duration_seconds summary
rpc_duration_seconds{quantile="0.01"} 3102
rpc_duration_seconds{quantile="0.05"} 3272
rpc_duration_seconds{quantile="0.5"} 4773
rpc_duration_seconds_sum 1.7560473e+07
rpc_duration_seconds_count 2693

在Exporter响应的HTTP头信息中,可以通过Content-Type指定特定的规范版本,例如:

1
2
3
4
HTTP/1.1 200 OK
Content-Encoding: gzip
Content-Length: 2906
Content-Type: text/plain; version=0.0.4

其中version用于指定Text-based的格式版本,当没有指定版本的时候,默认使用最新格式规范的版本。同时HTTP响应头还需要指定压缩格式为gzip。

参考内容

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