Prometheus服务发现和重新打标

Prometheus为何要进行服务发现

  Prometheus Server的数据抓取工作于Pull模型，因而，它必需要事先知道各Target的位置，然后才能从相应的Exporter中抓取数据。对于小型的系统环境来说，通过static_configs指定各Target便能解决问题，这也是最简单的配置方法；对于中大型的系统环境或具有较强动态性的容器环境来说，每个容器都有可能是一个抓取端点他随时可能创建或删除，静态配置显然难以适用。因此，Prometheus为此专门设计了一组服务发现机制，以便于能够基于服务注册中心自动发现、检测、分类可被监控的各Target，以及更新发生了变动的Target。

配置Prometheus实现自动服务发现

  Prometheus支持多种服务发现机制，具体自己需要使用哪种发现机制请查看官方网站，本文将根据本公司业务来讲解Prometheus结合consul来做服务发现和注册，这也是目前比较流行的一种做法。接下来，我们需要配置 Prometheus 来使用 Consul 自动服务发现。至于怎么安装consul请参考 高可用的SSL consul cluster实践 这里我就不在赘述了。注意：在注册到 Consul 时 name 字段可以相同，但是id 字段一定不能相同。

prometheus.yml 配置如下：

1
2
3
4
5
6
7
8
9
...
scrape_configs:
  - job_name: 'prometheus'
    consul_sd_configs:
     - server: "192.168.28.10:8500"
     - server: "192.168.28.11:8500"
     - server: "192.168.28.12:8500"
       datacenter: 'dc1'
       services: []

说明一下：这里需要使用 consul_sd_configs 来配置使用 Consul 服务发现类型，server 为 Consul 的服务地址, 配置完毕后重启 Prometheus 服务，此时可以通过 Prometheus UI 页面的 Targets 下查看是否配置成功。

Prometheus-config-2

通过consul的其中一个节点查看注册服务
Prometheus-config-3

可以看到，在 Targets 中能够成功的自动发现 Consul 中的 Services 信息，后期需要添加新的 Targets 时，只需要通过 API或JSON格式文件往 Consul 中注册服务即可，Prometheus 就能自动发现该服务，是不是很方便。

不过，我们会发现有如下几个问题：

  • 会发现 Prometheus 同时加载出来了默认服务 consul，这个是不需要的。
  • 默认只显示 job 及 instance 两个标签，其他标签都默认属于 before relabeling 下，有些必要的服务信息，也想要在标签中展示，该如何操作呢？
  • 如果需要自定义一些标签，例如 team、group、project 等关键分组信息，方便后边 alertmanager 进行告警规则匹配，该如何处理呢？
  • 所有 Consul 中注册的 Service 都会默认加载到 Prometheus 下配置的 prometheus 组，如果有多种类型的 exporter，如何在 Prometheus 中配置分配给指定类型的组，方便直观的区别它们？

以上问题，我们可以通过 Prometheus 配置中的 relabel_configs 参数来解决。

配置 relabel_configs 实现自定义标签及分类

  Prometheus 加载 Targets 后，这些 Targets 会自动包含一些默认的标签，这里的标签分两类；如果使用consul做服务发现则Target包含如下标签：不同的服务发现机制为其target添加的元标签会有所不同; Prometheus 允许用户在指标抓取前，通过 relabel_configs 来对 Target 标签进行重新标记(relabel) 。 常用于实现两个功能，一、将来自服务发现的元数据标签中的信息附加到指标的标签上； 二、过滤目标，可以针对标签的某个值进行过滤(处理问题一将使用这个功能)

Consul元标签：

1
2
3
4
5
6
7
8
9
10
11
12
__meta_consul_address
__meta_consul_dc
__meta_consul_health
__meta_consul_metadata_<key>
__meta_consul_node
__meta_consul_service_address
__meta_consul_service_id
__meta_consul_service_metadata_<key>
__meta_consul_service_port
__meta_consul_service
__meta_consul_tagged_address_<key>
__meta_consul_tags

Prometheus内置标签：

1
2
3
__address__
__metrics_path__
__scheme__

Prometheus-config-4

在上图我们我可以看到 Before relabeling 是重新标记以前的，而 Labels 中是重新标记以后的。

默认target的job标签设置为配置文件里的job_name的值;
__address__设置为配置里的targets的值;
而instance标签的值,是重定义标签操作之后__address__的值
__scheme__和__metrics_path__标签的值,也是从配置里取值的;
__param_<name>标签的值,是传给URL的查询参数<name>的值;

1
2
3
4
5
6
7
8
9
10
11
scrape_configs:
  - job_name: 'job'                           #实例名称
    static_configs:
    - targets: ['prometheus-server:9090']     #监控主机ip
    relabel_configs:                          #重新标记标签
    - source_labels: ['job']                  #源标签的名字
      separator: ;                            #源标签的分隔符，当有多个源标签的值的时候默认使用`;`连接
      regex: (.*)                             #使用正则匹配元标签的值，.*表示匹配所有
      action: replace                         #动作，replace动作就是将原来标签的值传给新标签
      replacement: $1                         #将正则表达式匹配到的结果值引用给新标签
      target_label: idc                       #新标签的名称

对 Target 重新打标是在数据抓取之前动态重写 Target 标签的强大工具，在配置中可以定义多个relabel步骤，它们将按照定义的顺序依次执行;重新标记完成后，该 Target 上以“__”开头的所有标签都会被移除;
详细 relabel_configs 配置及说明可以参考 relabel_config 官网说明，这里我简单列举一下里面每个 relabel_action 的作用，方便下边演示。

  • replace: 根据 regex 的配置匹配 source_labels 标签的值（注意：source_label 中有多个元标签时，则他们的值会按照 separator 进行拼接），并且将匹配到的值写入到 target_label 当中，如果有多个匹配组，则可以使用 ${1}, ${2} 确定写入的内容。如果没匹配到任何内容则不对 target_label 进行重写， 默认为 replace。
  • keep: 丢弃 source_labels 的值中没有匹配到 regex 正则表达式内容的 Target 实例
  • drop: 丢弃 source_labels 的值中匹配到 regex 正则表达式内容的 Target 实例
  • hashmod: 将 target_label 设置为关联的 source_label 的哈希模块
  • labelmap: 根据 regex 去匹配 Target 实例所有标签的名称（注意是名称），并且将捕获到的内容作为为新的标签名称，regex 匹配到标签的的值作为新标签的值
  • labeldrop: 将 regex 对所有的标签名进行匹配判定，能够匹配到的标签将从该 Target 的标签集中删除;
  • labelkeep: 将 regex 对所有的标签名进行匹配判定，不能匹配到的标签将从该 Target 的标签集中删除;

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
- job_name: 'node-exporter'
  consul_sd_configs:
   - server: "192.168.28.10:8500"
   - server: "192.168.28.11:8500"
   - server: "192.168.28.12:8500"
     datacenter: 'dc1'
     services: []
  relabel_configs:
   - source_labels: [__meta_consul_service]
     regex: ".*node-exporter.*"
     action: keep
   - source_labels: [__scheme__, __address__, __metrics_path__]
     regex: "(http|https)(.*)"    # 两个分组
     separator: ""
     target_label: "endpoint"
     replacement: "${1}://${2}"   # 引用两个分组
     action: replace

Prometheus-config-20

当有多个源标签的值时如果不设置separator为空则每个源标签的值将使用;做连接
Prometheus-config-21

处理上述问题

问题一，首先我们鼠标指向labels下的某一个target的元标签时可以看到，使用consul做服务发现时会自动添加的元标签。细心的我们在查看consul注册进来的服务发现__meta_consul_service标签的值都是consul。那么我们可以配置 relabel_configs 来实现标签过滤，只加载符合规则的服务。
Prometheus-config-5

修改 prometheus.yml 配置如下：

1
2
3
4
5
6
7
8
9
10
11
12
scrape_configs:
  - job_name: 'prometheus'
    consul_sd_configs:
     - server: "192.168.28.10:8500"
     - server: "192.168.28.11:8500"
     - server: "192.168.28.12:8500"
       datacenter: 'dc1'
       services: []
    relabel_configs:
     - source_labels: [__meta_consul_service]
       regex: "consul"
       action: drop

解释下，这里的 relabel_configs 配置作用为如果元标签 __meta_consul_service 的值是 consul 的服务则丢弃，__meta_consul_service 的值对应到 Consul 服务中的值为"name":字段,重启 Prometheus 可以看到现在只获取了 node-exporter-192.168.28.13 这个服务了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
  "service": {
    "id": "node-01",
    "name": "node-1",           # 注意：此值是可以在别的service中重复出现的
    "tags": ["ngx_exporter","prod","xcws","monitor"],
    "address": "192.168.28.13",
    "port": 9100,
    "Meta": {
      "app": "spring-boot",
      "team": "appgroup",
      "project": "bigdata"
    },
    "check": {
       "id": "node-01",
       "name": "node-1", 
       "http": "http://192.168.28.13:9100/metrics",
       "interval": "10s",
       "timeout": "1s"
  }
  }
}

Prometheus-config-6

问题二和问题三可以归为一类，就是将系统默认标签或者用户自定义标签转换成可视化标签，方便查看及后续 Alertmanager 进行告警规则匹配分组。不过要实现给服务添加自定义标签，我们还得做一下修改，就是在注册服务时，将自定义标签信息添加到 Meta Data 数据中，下边来演示一下如何操作。

新建 consul-0.json 如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
  "service": {
    "id": "node-01",
    "name": "node-1",
    "tags": ["ngx_exporter","prod","xcws","monitor"],
    "address": "192.168.28.13",
    "port": 9100,
    "Meta": {
      "app": "spring-boot",
      "team": "appgroup",
      "project": "bigdata"
    },
    "check": {
       "id": "node-01",
       "name": "node-1", 
       "http": "http://192.168.28.13:9100/metrics",
       "interval": "10s",
       "timeout": "1s"
  }
  }
}

说明一下：该 Json 文件为要注册的服务信息，同时往 Meta 信息中添加了 app=spring-boot，team=appgroup，project=bigdata 三组标签，目的就是为了方便告警分组使用。

重启 Consul 服务后注册完毕，通过 Consul Web 管理页面可以查看到已注册成功，并且包含了 Meta 信息。

Prometheus-config-7

然后修改 prometheus.yml 配置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
scrape_configs:
  - job_name: 'prometheus'
    consul_sd_configs:
     - server: "192.168.28.10:8500"
     - server: "192.168.28.11:8500"
     - server: "192.168.28.12:8500"
       datacenter: 'dc1'
       services: []
    relabel_configs:
     - source_labels: [__meta_consul_service]
       regex: "consul"
       action: drop
     - regex: __meta_consul_service_metadata_(.+)
       replacement: ${1}
       action: labelmap

解释一下，增加的配置作用为匹配 __meta_consul_service_metadata_ 开头的标签，将捕获到的内容作为新的标签名称，匹配到标签的值作为新标签的值，而我们刚添加的三个自定义标签，系统会自动添加 __meta_consul_service_metadata_app=spring-boot 、__meta_consul_service_metadata_team=appgroup、__meta_consul_service_metadata_project=bigdata 三个标签，经过 relabel 后，Prometheus 将会新增 app=spring-boot、team=appgroup、project=bigdata 三个标签。重启 Prometheus 服务，可以看到新增了对应了三个自定义标签。

Prometheus-config-8

relabel示例之labelmap最简单示例

1
2
3
4
5
6
7
8
- job_name: 'nodes' file_sd_configs:
  file_sd_configs:
  - files:
    targets/prometheus/node*.yaml
  relabel_configs:
  - regex: "(job|app)"
    replacement: ${1}_name
    action: labelmap

生成的结果如下图所示(注意这里是配了的是标签名称job和app都是存在的)

Prometheus-config-10

relabel示例之labeldrop最简单示例

1
2
3
4
5
6
7
8
9
10
- job_name: 'nodes' file_sd_configs:
  file_sd_configs:
  - files:
    targets/prometheus/node*.yaml
  relabel_configs:
  - regex: "(job|app)"
    replacement: ${1}_name
    action: labelmap
  - regex: "(app)"
    action: labeldrop

生成的结果如下图所示(删除标签为app的标签)
Prometheus-config-17

另外一种处理方式，可以看到上面的 consul-0.json 文件中定义了 tags 这个字段。我们也可以使用这里的 tags 的值来自定义标签。

Prometheus-config-9

修改 prometheus.yml 配置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
scrape_configs:
  - job_name: 'prometheus'
    consul_sd_configs:
     - server: "192.168.28.10:8500"
     - server: "192.168.28.11:8500"
     - server: "192.168.28.12:8500"
       datacenter: 'dc1'
       services: []
    relabel_configs:
     - source_labels: [__meta_consul_service]
       regex: "consul"
       action: drop
     - regex: __meta_consul_service_metadata_(.+)
       replacement: ${1}
       action: labelmap
     - source_labels: ["__meta_consul_tags"]
       regex: ",(.+),(.+),(.+),(.+),"
       replacement: $1
       action: replace
       target_label: exporter_type
     - source_labels: ["__meta_consul_tags"]
       regex: ",(.+),(.+),(.+),(.+),"
       replacement: $2
       action: replace
       target_label: env
     - source_labels: ["__meta_consul_tags"]
       regex: ",(.+),(.+),(.+),(.+),"
       replacement: $3
       action: replace
       target_label: job
     - source_labels: ["__meta_consul_tags"]
       regex: ",(.+),(.+),(.+),(.+),"
       replacement: $4
       action: replace
       target_label: platform

解释一下，这里配置的 __meta_consul_tags 对应到 Consul 注册服务的 Tags 字段,使用 regex 去匹配将匹配到的结果分为4组，然后replacement可按需引用 regex 中的某个“分组”匹配到的值，并赋值给 target_label 标签。形成一个 k=v 格式。

问题四，将自动发现的服务进行分类，本质上跟上边的处理方式一致，可以通过服务 Tag 来进行匹配创建不同的类型 exporter 分组。通过给每个服务标记不同的 Tag，然后通过 relabel_configs 来进行匹配区分。我们来更新一下原有的consul-0.json 文件修改服务标签，同时注册一个其他类型 exporter 的服务如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
  "service": {
    "id": "node-01",
    "name": "node-1",
    "tags": ["node-exporter"],         //修改
    "address": "192.168.28.13",
    "port": 9100,
    "Meta": {
      "app": "spring-boot",
      "team": "appgroup",
      "project": "bigdata"
    },
    "check": {
       "id": "node-01",
       "name": "node-1", 
       "http": "http://192.168.28.13:9100/metrics",
       "interval": "10s",
       "timeout": "1s"
  }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
  "service": {
    "id": "cadvisor-exporter",     
    "name": "node-1",
    "tags": ["cadvisor-exporter"],      //修改
    "address": "192.168.28.13",
    "port": 8080,
    "Meta": {
    "app": "docker",
    "team": "cloudgroup",
    "project": "docker-service"
    },
    "check": {
       "http": "http://192.168.28.13:8080/metrics",
       "interval": "10s",
       "timeout": "1s"
  }
  }
}

说明一下，我们更新了原有 consul-0.json 文件中服务的标签为 node-exporter，同时注册一个新类型 cadvisor-exporter 服务，并设置标签为 cadvisor-exporter，以示区别。注册完毕，通过 Consul Web 控制台可以看到成功注册了这两个服务。这里需要说明一下，在上面的两个JSON文件中我们都使用的是同一个 Name 名字所以我们需要点进 node-1 这个 service 名字下才能看到两个服务

Prometheus-config-11

最后，我们修改 prometheus.yml 配置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
scrape_configs:
  - job_name: 'consul-node-exporter'
    consul_sd_configs:
     - server: "192.168.28.10:8500"
     - server: "192.168.28.11:8500"
     - server: "192.168.28.12:8500"
       datacenter: 'dc1'
       services: []
    relabel_configs:
     - source_labels: [__meta_consul_tags]
       regex: ".*node-exporter.*"
       action: keep
     - regex: __meta_consul_service_metadata_(.+)
       replacement: ${1}
       action: labelmap

  - job_name: 'consul-cadvisor-exproter'
    consul_sd_configs:
     - server: "192.168.28.10:8500"
     - server: "192.168.28.11:8500"
     - server: "192.168.28.12:8500"
       datacenter: 'dc1'
       services: []
    relabel_configs:
     - source_labels: [__meta_consul_tags]
       regex: ".*cadvisor-exporter.*"
       action: keep
     - regex: __meta_consul_service_metadata_(.+)
       replacement: ${1}
       action: labelmap

这里需要根据每种类型的 exporter 新增一个关联 job，同时 relabel_configs 中配置 __meta_consul_tags 以 Tag 来做匹配区分。这里的 relabel_configs 配置作用为丢弃元标签中 __meta_consul_tags 的值不包含 node-exporter 或 cadvisor-exporter 标签的服务，从上面的配置来看两个Job实现了互斥，从而实现过滤。重启 Prometheus 服务，可以看到服务已经按照类型分类了，方便查看。

Prometheus-config-12

Prometheus黑盒监控

&emsp;&emsp;常规的各种exporter都是和需要监控的机器一起安装的,如果需要监控一些tcp端口和七层应用层的状态呢,这个时候就需要黑盒监控了,不需要安装在目标机器上即可从外部去监控。（如果想做到A访问B则需要在A机器上安装blackbox让A去请求B，而不是从某一个固定的机器去访问。这样做点对点监控） blackbox默认的http监听端口是9115，blackbox.yml的配置文件里有基础的https、http、dns、tcp、icmp配置，prober 定制配置出各种监测模块(module)，在prometheus server的配置文件里声明用哪个模块去探测哪个targets。

安装配置blackbox_exporter

下载blackbox_exporter

1
2
3
wget https://github.com/prometheus/blackbox_exporter/releases/download/v0.19.0/blackbox_exporter-0.19.0.linux-amd64.tar.gz

tar -zxv -f blackbox_exporter-0.19.0.linux-amd64.tar.gz

修改 blackbox.yml 配置文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
modules:
  http_2xx:           # 模块名字,符合规则随便命名即可
    prober: http      # 探针类型
    http:
      valid_status_codes: [200,201,202,203,204,205,206,207,300,301,302,303,304,305,306,307,405]
  http_post_2xx:
    prober: http
    http:
      method: POST
  tcp_connect:
    prober: tcp
  pop3s_banner:
    prober: tcp
    tcp:
      query_response:
      - expect: "^+OK"
      tls: true
      tls_config:
        insecure_skip_verify: false
  ssh_banner:
    prober: tcp
    tcp:
      query_response:
      - expect: "^SSH-2.0-"
  irc_banner:
    prober: tcp
    tcp:
      query_response:
      - send: "NICK prober"
      - send: "USER prober prober prober :prober"
      - expect: "PING :([^ ]+)"
        send: "PONG ${1}"
      - expect: "^:[^ ]+ 001"
  icmp:
    prober: icmp

修改 Prometheus.yml 配置文件文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
- job_name: 'http_2xx'
  consul_sd_configs:
   - server: "192.168.28.10:8500"
   - server: "192.168.28.11:8500"
   - server: "192.168.28.12:8500"
     datacenter: 'dc1'
     services: []
  metrics_path: /probe
  params:
     module: [http_2xx]        # HTTP URL参数
  relabel_configs:
   - source_labels: [__meta_consul_service]
     regex: "http_2xx"
     action: keep       
   - source_labels: [__meta_consul_service_address]
     target_label: __param_target
   - source_labels: [__param_target]
     target_label: instance
   - target_label: __address__
     replacement: 192.168.28.10:9115

解释：新创建一个Job名为 http_2xx 并设置仅抓取 __meta_consul_service 元标签中值为 http_2xx 的target，然后将元标签__meta_consul_service_address的值赋值给一个新的标签__param_target 其中最后变成target=xxx.xxx.xxx.xxx的格式（xxx为IP地址），然后在将__param_target的值重新写入给instance这个标签，这个标签原先已经有值了，所以这里会instance原来的值会被替换为__param_target的值。在然后__address__的值会被修改为192.168.28.10:9115这个IP。我们需要注意的是标签存在则覆盖，标签不存在则创建

Prometheus-config-13

从下图可以看到实际在请求的是的是带入了一些参数module=http_2xx&target=www.baidu.com 其中 module=http_2xx 是 prometheus.yaml 中配置的，而target=www.baidu.com 是__param_target 传入的。
Prometheus-config-16

注册服务到 Consul

1
2
3
4
5
6
7
8
9
[root@k8s-n1 client]# cat http_p2p.json 
{
  "service": {
    "id": "test-http",
    "name": "http_2xx",
    "tags": ["blackbox_export","prod","xcws","192.168.28.13:9115","httpp2p"],
    "address": "www.baidu.com"
  }
}

Prometheus-config-14

从上面的方式我们可以做到tcp端口和七层应用层监控，但是有一个问题。所有的请求都是从192.168.28.10这台安装了 blackbox_exporter主机发起的，如果我们想做点对点监控呢？那么我们需要在发起请求的主机上安装 blackbox_exporter。下面将讲解如何配置点对点监控，这里用到tag的方式来进行点对点监控，需要多注意看配置文件。

Consul注册文件：

1
2
3
4
5
6
7
8
{
  "service": {
    "id": "test-http",
    "name": "http_2xx",
    "tags": ["blackbox_export","prod","xcws","192.168.28.13:9115","httpp2p"],
    "address": "www.baidu.com"
  }
}

Prometheus配置文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
- job_name: 'http_2xx'
  consul_sd_configs:
   - server: "192.168.28.10:8500"
   - server: "192.168.28.11:8500"
   - server: "192.168.28.12:8500"
     datacenter: 'dc1'
     services: []
  metrics_path: /probe
  params:
     module: [http_2xx]
  relabel_configs:
   - source_labels: [__meta_consul_service]
     regex: "http_2xx"
     action: keep
   - source_labels: [__meta_consul_service_address]
     target_label: __param_target
   - source_labels: [__param_target]
     target_label: instance
   - source_labels: [__meta_consul_tags]
     regex: ",(.+),(.+),(.+),(.+),(.+),"
     action: replace
     replacement: $4
     target_label: __address__

解释一下我们做了些什么工作，首先我们先在 192.168.28.13 上安装 blackbox_exporter 并修改 blackbox.yml 配置文件。从上面注册到 Consul 中的信息可以看到我们在 Tags 中添加了一个IP，然后我们在下面的Prometheus中去分组匹配，上面的tags中有5段，这里我们在Prometheus中也使用5个分组去匹配。我们可以看到 192.168.28.13:9115 属于第四段，所以我们在replacement中引用第四个分组。然后将结果赋值给新的标签__address__。

Prometheus-config-15

这样配置我们可以看到发送请求的地址是 192.168.28.13 这个IP，而不是像最上面那样从某一个固定的IP（192.168.28.10）发起的请求。如果我们需要在多个机器上实现这种点对点监控。请在所有的机器上都安装 blackbox_exporter 。

对抓取到的metric重新打标

对metric重新打标是在数据抓取之后动态重写metric标签的工具，在每个数据抓取配置中，可以定义多个metric relabel的步骤，它们将按照定义的顺序依次执；metric_relabel_configs 模块和 relabel_config 模块很相似。metric_relabel_configs 一个很常用的用途：将监控不需要的数据，直接丢掉，不在Prometheus 中保存。

重新标记操作一般常见的情况

  • 删除不必要的指标。
  • 从指标中删除敏感或不需要的标签。
  • 添加、编辑或者修改指标的标签值或者标签格式。

一、删除不需要的指标(metric)

Prometheus 默认会将所有拉取到的 metrics 都写入自己的存储中。如果某些 metrics 对我们并没有太多意义，可以设置直接丢掉，减少磁盘空间的浪费。例如删除 go_info 的指标数据。通过指标上元标签 __name__ 引用指标名称，而后由 regex 进行匹配判定，可使用drop action删除匹配的指标，或使用keep action仅保留匹配的指标;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
scrape_configs:
  - job_name: 'consul-node-exporter'
    consul_sd_configs:
     - server: "192.168.28.10:8500"
     - server: "192.168.28.11:8500"
     - server: "192.168.28.12:8500"
       datacenter: 'dc1'
       services: []
    relabel_configs:
     - source_labels: [__meta_consul_tags]
       regex: ".*node-exporter.*"
       action: keep
    metric_relabel_configs:
     - source_labels: [ __name__ ]
       regex:  "go_info"
       action: drop

  - job_name: 'consul-cadvisor-exproter'
    consul_sd_configs:
     - server: "192.168.28.10:8500"
     - server: "192.168.28.11:8500"
     - server: "192.168.28.12:8500"
       datacenter: 'dc1'
       services: []
    relabel_configs:
     - source_labels: [__meta_consul_tags]
       regex: ".*cadvisor-exporter.*"
       action: keep
    metric_relabel_configs:
     - source_labels: [ __name__ ]
       regex:  "go_info"
       action: drop

metric relabel示例之删除指标

下面的第一个图为执行go_info为前缀的指标删除之前的查询结果，而第二个图则是删除相关指标之后的查询结果;

  • 提示:若删除的指标此前曾由Prometheus抓取并存储过相关的样本数据，则删除操作的 需要经过一定的时长后才会反映至查询结果中;

Prometheus-config-18

Prometheus-config-19

二、修改指标(metric) 中的标签(label)

如果我们使用 Prometheus 监控 Kubernetes 运行状态；应该会遇到，在一个 query 中结合一个以上的job_name(metric_source)的情况。 不同的 job_name 中metric的label命名可能不相同。比如：pod的名称可以使用pod或者 pod_name 这两个 label 记录。如果相同含义的label，名称却不相同；对query的编写就很困难了。至少我没有在 PromQL 中找到类似 SQL 语句中的 as 的功能的关键词和方法。 这样的话，正确的解决思路应该是在 Prometheus 拉取数据后，保存数据前；将 label 的名称进行重写；保证相同含义的 label 有相同的名称。

1
2
3
4
5
6
7
8
9
10
11
12
13
metric_relabel_configs:
- source_labels: [pod]
  separator: ;
  regex: (.+)
  target_label: pod_name
  replacement: $1
  action: replace
- source_labels: [container]
  separator: ;
  regex: (.+)
  target_label: container_name
  replacement: $1
  action: replace

如上，将指定job_name中，所有的metrics中含有名为pod和container名称的label分别拷贝到名为pod_name，container_name的label中。 注意：如果metric 的 label 的名称包含了pod和container关键词，但是不等于；则不会处理此label。

三、删除标签

删除标签通常用于隐藏敏感信息或者简化时间序列。

1
2
3
metric_relabel_configs:
- regex: 'kernelVersion'
  action: labeldrop

为了删除标签，我们指定了一个正则表达式，然后指定删除标签的操作labeldrop。 这将删除与正在表达式匹配的所有标签。

relabel_configs在Kubernetes中的一些用法

1
2
3
4
5
6
7
8
9
10
11
12
- source_labels: [__meta_kubernetes_endpoint_address_target_kind, __meta_kubernetes_endpoint_address_target_name]
  separator: ;
  regex: Node;(.*)
  target_label: node
  replacement: ${1}
  action: replace
- source_labels: [__meta_kubernetes_endpoint_address_target_kind, __meta_kubernetes_endpoint_address_target_name]
  separator: ;
  regex: Pod;(.*)
  target_label: pod
  replacement: ${1}
  action: replace

当__meta_kubernetes_endpoint_address_target_kind值是Node的时候那么他将匹配到一个relabel，因为正则表达式里面已经写明了一个源标签的值是Node不然匹配不到

Prometheus-config-22

当__meta_kubernetes_endpoint_address_target_kind值是Pod的时候那么他将匹配到二个relabel，因为正则表达式里面已经写明了一个源标签的值是Pod不然匹配不到

Prometheus-config-23

Prometheus服务发现和重新打标
https://system51.github.io/2021/05/18/Prometheus-service-discovery-and-relabel-configs/
作者
Mr.Ye
发布于
2021年5月18日
许可协议