prometheus 使用 普罗米修斯

一、使用普罗米修斯***Prometheus***入门

官方文档

Prometheus从被监控目标设备通过检索 metrics HTTP endpoints收集metrics。普罗因为Prometheus自身也以同样的米修方式发布数据，所以它也可以监控自身的使用健康状态。

虽然Prometheus server仅采集自身的普罗数据没什么意义，但是米修作为开始的范例很合适。

将下面的使用内容保存为 Prometheus配置文件prometheus.yml：

实际上安装包内已经包含了该文件，无需修改

查看其他配置项，普罗请参阅 configuration documentation。米修

新开一个bash shell，使用查看服务和端口

访问测试

访问测试

我们试试查看Prometheus收集的普罗自身的数据。要使用 Prometheus自带的米修 expression browser，导航到 ，使用选择"Graph" tab内的普罗"Console" view。

既然你可以从 localhost:9090/metrics查看数据，米修那么可以看到一个Prometheus自己发布的指标 prometheus_target_interval_length_seconds(目标采集的实际间隔实际)。输入到expression console，然后点击"Execute":

如上，返回了一些不同的时间序列(along with the latest value recorded for each),都是 prometheus_target_interval_length_seconds的metric name，但是拥有不同的标签。这些标签显示了不同的时间段( latency percentiles)和目标组间隔(target group intervals)。

如果我们只对 99th percentile latencies有兴趣，我们可以通过如下查询：

要统计返回的时间序列数量，可以查询如下：

更多表达式语言参见 expression language documentation.

要图形表示，导航到 ，点击"Graph" tab。

比如，使用如下查询，图形表示demo Prometheus的per-second rate of chunks：

Experiment with the graph range parameters and other settings.

开始接入几个sample targets来演示。

Node Exporter用来作为范例，怎么使用参见 see these instructions.

范例监听在 , , and 。

现在我们配置 Prometheus来采集这些对象。我们把三个endpoints组成一个group到job内，称为node。假设，前两个是生产，第三个是金丝雀实例。为了在Prometheus区分，我们增加了数个endpoint组，给每个组增加标签。在范例中，我们将增加 group="production"标签给第一个组， group="canary"给第二个。

要实现这些，在prometheus.yml文件添加如下job定义到scrape_configs section，然后重启Prometheus实例。

回到 expression browser，确认 Prometheus现在已经有了关于这三个范例的信息，比如查询

虽然在范例中没有这个问题，但是当computed ad-hoc，跨成千上万时间序列的查询会变慢。为提升效率， Prometheus允许通过配置recording rules将预记录的表达式插入到新时间序列中。假设我们需要5分钟时间窗口(job, instance and mode dimensions)的平均值 per-second rate of cpu time(node_cpu_seconds_total)。我们可以查询如下：

实施图形展示。

要将这个表达式的值放到一个新metric job_instance_mode:node_cpu_seconds:avg_rate5m，使用下面的recording rule保存为 prometheus.rules.yml:

要让 Prometheus使用这个 rule，在 prometheus.yml添加 rule_files声明部分。如下是范例：

使用新配置文件重启 Prometheus，确认一个新指标 job_instance_mode:node_cpu_seconds:avg_rate5m可以通过expression browser查询了。

二、Prometheus 查询语言

[TOC]

PromQL（Prometheus Query Language）是 Prometheus自己开发的表达式语言，语言表现力很丰富，内置函数也很多。使用它可以对时序数据进行筛选和聚合。

PromQL表达式计算出来的值有以下几种类型：

瞬时向量选择器用来选择一组时序在某个采样点的采样值。

最简单的情况就是指定一个度量指标，选择出所有属于该度量指标的时序的当前采样值。比如下面的表达式：

可以通过在后面添加用大括号包围起来的一组标签键值对来对时序进行过滤。比如下面的表达式筛选出了 job为 prometheus，并且 group为 canary的时序：

匹配标签值时可以是等于，也可以使用正则表达式。总共有下面几种匹配操作符：

下面的表达式筛选出了 environment为 staging或 testing或 development，并且 method不是 GET的时序：

度量指标名可以使用内部标签 __name__来匹配，表达式 http_requests_total也可以写成{ __name__="http_requests_total"}。表达式{ __name__=~"job:.*"}匹配所有度量指标名称以 job:打头的时序。

区间向量选择器类似于瞬时向量选择器，不同的是它选择的是过去一段时间的采样值。可以通过在瞬时向量选择器后面添加包含在 []里的时长来得到区间向量选择器。比如下面的表达式选出了所有度量指标为 http_requests_total且 job为 prometheus的时序在过去 5分钟的采样值。

说明：时长的单位可以是下面几种之一：

前面介绍的选择器默认都是以当前时间为基准时间，偏移修饰器用来调整基准时间，使其往前偏移一段时间。偏移修饰器紧跟在选择器后面，使用 offset来指定要偏移的量。比如下面的表达式选择度量名称为 http_requests_total的所有时序在 5分钟前的采样值。

下面的表达式选择 http_requests_total度量指标在 1周前的这个时间点过去 5分钟的采样值。

PromQL的二元操作符支持基本的逻辑和算术运算，包含算术类、比较类和逻辑类三大类。

算术类二元操作符有以下几种：

算术类二元操作符可以使用在标量与标量、向量与标量，以及向量与向量之间。

二元操作符上下文里的向量特指瞬时向量，不包括区间向量。

比较类二元操作符有以下几种：

比较类二元操作符同样可以使用在标量与标量、向量与标量，以及向量与向量之间。默认执行的是过滤，也就是保留值。

也可以通过在运算符后面跟 bool修饰符来使得返回值 0和 1，而不是过滤。

逻辑操作符仅用于向量与向量之间。

具体运算规则如下：

PromQL的各类二元操作符运算优先级如下：

前面算术类和比较类操作符都需要在向量之间进行匹配。共有两种匹配类型， one-to-one和 many-to-one/ one-to-many。

这种匹配模式下，两边向量里的元素如果其标签键值对组合相同则为匹配，并且只会有一个匹配元素。可以使用 ignoring关键词来忽略不参与匹配的标签，或者使用 on关键词来指定要参与匹配的标签。语法如下：

比如对于下面的输入：

执行下面的查询：

得到的结果为：

也就是每一种 method里 code为 500的请求数占总数的百分比。由于 method为 put和 del的没有匹配元素所以没有出现在结果里。

这种匹配模式下，某一边会有多个元素跟另一边的元素匹配。这时就需要使用 group_left或 group_right组修饰符来指明哪边匹配元素较多，左边多则用 group_left，右边多则用 group_right。其语法如下：

组修饰符只适用于算术类和比较类操作符。

对于前面的输入，执行下面的查询：

将得到下面的结果：

也就是每种 method的每种 code错误次数占每种 method请求数的比例。这里匹配的时候 ignoring了 code，才使得两边可以形成 Many-to-one形式的匹配。由于左边多，所以需要使用 group_left来指明。

Many-to-one/ one-to-many过于高级和复杂，要尽量避免使用。很多时候通过 ignoring就可以解决问题。

PromQL的聚合操作符用来将向量里的元素聚合得更少。总共有下面这些聚合操作符：

聚合操作符语法如下：

其中 without用来指定不需要保留的标签（也就是这些标签的多个值会被聚合），而 by正好相反，用来指定需要保留的标签（也就是按这些标签来聚合）。

下面来看几个示例：

http_requests_total度量指标带有 application、instance和 group三个标签。上面的表达式会得到每个 application的每个 group在所有 instance上的请求总数。效果等同于下面的表达式：

下面的表达式可以得到所有 application的所有 group的所有 instance的请求总数。

Prometheus内置了一些函数来辅助计算，下面介绍一些典型的。

三、prometheus配置详解

本文按照官方文档的相关内容整理整理的配置语法以及实现功能

一个scrape_config片段指定一组目标和参数，目标就是实例，指定采集的端点，参数描述如何采集这些实例，配置文件格式如下

因为部署在kubernetes环境中所以我只在意基于kubernetes_sd_configs的服务发现和static_configs静态文件的发现

relable_configss是功能强大的工具，就是Relabel可以在Prometheus采集数据之前，通过Target实例的Metadata信息，动态重新写入Label的值。除此之外，我们还能根据Target实例的Metadata信息选择是否采集或者忽略该Target实例。

relabel_configs

配置格式如下：

其中action主要包括:

replace：默认，通过regex匹配source_label的值，使用replacement来引用表达式匹配的分组

keep：删除regex与连接不匹配的目标 source_labels

drop：删除regex与连接匹配的目标 source_labels

labeldrop：删除regex匹配的标签

labelkeep：删除regex不匹配的标签

hashmod：设置target_label为modulus连接的哈希值source_labels

labelmap：匹配regex所有标签名称。然后复制匹配标签的值进行分组，replacement分组引用（{ 2},…）替代

prometheus中的数值都是key:value格式，其中replace、keep、drop都是对value的操作， labelmap、labeldrop、labelkeep都是对key的操作

replace是action的默认值，通过regex匹配source_label的值，使用replacement来引用表达式匹配的分组

上面的列子中 address的值为$1:$2，其中$1是正则表达式([^:]+)(?::\d+)?从 address中获取，$2是正则表达式(\d+)从(\d+)中获取，最后的 address的数值为192.168.1.1:9100

上面的例子只要匹配__meta_kubernetes_service_annotation_prometheus_io_probe=true数据就保留，反正source_labels中的值没有匹配regex中的值就丢弃

drop的使用和keep刚好相反，还是使用keep的例子:

上面的例子只要__meta_kubernetes_service_annotation_prometheus_io_probe这个标签的值为true就丢弃，反之如果__meta_kubernetes_service_annotation_prometheus_io_probe!=true的数据就保留

labelmap的用法和上面说到replace、keep、drop不同， labelmap匹配的是标签名称，而replace、keep、drop匹配的是value

上面例子中只要匹配到正则表达式 __meta_kubernetes_service_label_(.+)的标签，就将标签重写为(.+)中的内容，效果如下：

待续

使用labeldrop则可以对Target标签进行过滤，删除符合过滤条件的标签，例如：

该配置会使用regex匹配当前target中的所有标签，删除符合规则的标签，反之保留不符合规则的

使用labelkeep则可以对Target标签进行过滤，仅保留符合过滤条件的标签，例如：

该配置会使用regex匹配当前target中的所有标签，保留符合规则的标签，反之不符合的移除

上面我们说到relabel_config是获取metrics之前对标签的重写，对应的metric_relabel_configs是对获取metrics之后对标签的操作， metric_relabel_configs能够确定我们保存哪些指标，删除哪些指标，以及这些指标将是什么样子。

metric_relabel_configs的配置和relabel_config的配置基本相同，如果需要配置相关参数请参考 2.scrape_configs

主要用途为指定exporter获取metrics数据的目标，可以指定prometheus、 mysql、 nginx等目标

此规则主要是用于抓取prometheus自己数据的配置， targets列表中的为prometheus获取metrics的地址和端口，因为没有指定metrics_path所以使用默认的/metrics中获取数据，

简单理解就是， prometheus访问 获取监控数据

还可以配置指定exporter中的目的地址，如获取node_exporter的数据

简单理解为分别访问 获取metrics数据

kubernetes的服务发现可以刮取以下几种数据

通过指定kubernetes_sd_config的模式为endpoints，Prometheus会自动从Kubernetes中发现到所有的endpoints节点并作为当前Job监控的Target实例。如下所示，

该配置是使用kubernetes的发现机制发现kube-apiservers

上面的刮取配置定义了如下信息：

该配置是自动发现kubernetes中的endpoints

可以看到relable_configs中的规则很多，具体的内容如下

获取的metrics的信息如下：

参考资料:可观测性平台