# Prometheus 服务发现与 Relabel
# 一. Prometheus 服务发现
# 1.1 为什么需要服务发现
Prometheus 采⽤ Pull 模型来抓取⽬标主机的指标数据，这就意味着 Prometheus 必须事先知道每个要监控的⽬标的端点地址。然后才能从对应的 Exporter 或 Instrumentation 进⾏数据抓取。对于规模较⼩，且监控的⽬标不会频繁的发⽣变动，直接使⽤ static_configs 静态配置来监控它们，就⾮常简便。
但是，当我们⾯对容器应⽤的场景时，会发现监控的这些⽬标端点可能会频繁的发⽣变化。因此使⽤静态配置⽅法可能不太适⽤了。那么 Prometheus 为了适应这种动态性，引⼊了多种类型的服务发现机制。这些机制使得 Prometheus 能够动态地从 “服务注册中⼼” ⾃动的发现可被监控的⽬标。即使监控的⽬标端发⽣了变化，Prometheus 也能⾃动的发现这些变化并对相应的配置进⾏⾃动更新，⽽⽆需认为参与。⼤⼤的降低了维护成本。
# 1.2 服务发现的实现⽅式
Prometheus 的服务发现（Service Discovery, SD）可以与各种不同的服务发现系统集成，从⽽⾃动发现监控⽬标。以下是⼀些常⻅的服务发现机制的实现⽅式：
- 1、静态服务配置：可以通过配置⽂件指定固定地址和端⼝，对⽬标服务进⾏监控。
- 2、基于⽂件的发现机制：以配置⽂件作为发现的源头，通过监控这些⽂件的变动来动态调整监控⽬标的增加或减少。通常会配合如像 Ansible 这样的⼯具⼀起使⽤，对配置⽂件进⾏批量更新，只需要让 Prometheus 重新加载这些配置，就能⾃动适应新的监控环境。
- 3、基于注册中⼼的发现机制：在微服务架构中，常常会使⽤ Consul 等服务注册中⼼来管理所有的服务。Prometheus 可以读取 Consul 中的服务列表，从⽽⾃动发现并开始监控所有注册的服务。
- 4、基于公有云 API 的发现机制：当你需要监控公有云上的 RDS 服务时，⼀条条配置⾮常麻烦，这个时候就可以使⽤ Prometheus 基于公有云的 OpenAPI 进⾏服务发现。例如，配置 Prometheus ⾃动拉取 AWS 账号下所有 RDS 实例的列表，从⽽实现对所有数据库实例的监控。
- 5、基于 Kubernetes 的发现机制：在 Kubernetes 环境中，Prometheus 可以通过调⽤ kube-apiserver 获取集群中的 Node、Pod、Endpoint、Ingress 等信息。例如，如果你在 Kubernetes 集群中部署了⼀个新的应⽤，Prometheus 可以⾃动发现并开始监控这个新的 Pod。
- 6、基于 DNS、HTTP 等等服务发现，使⽤的不多，就不⼀⼀展开， 更多服务发现⽅式参考地址。
# 二. Prometheus 基于⽂件服务发现
# 2.1 基于⽂件服务发现介绍
Prometheus 基于⽂件的服务发现⾮常的简单，因为它不依赖任何特定的平台或第三⽅服务。
⽤户只需在 Prometheus 配置⽂件中指定 file_sd_configs 选项来监视⼀个⽂件。这个⽂件包含了要监控的⽬标列表。那么 Prometheus 则会周期性地检查该⽂件，⼀旦发现有任何变更，则会⽴即更新对应的监控⽬标。
# 2.2 基于⽂件服务发现实践
将此前的 node_exporter 修改为基于⽂件发现的⽅式
1、配置 Prometheus
scrape_configs: | |
- job_name: "node_exporter" | |
file_sd_configs: | |
- files: | |
- /etc/prometheus/targets/node*.yml # 指定⽂件路径 | |
refresh_interval: 1m # 刷新间隔，默认 1m |
2、定义发现规则⽂件（将 node01 和 node02 添加⼀个 env=prod 的标签，将 node03 添加 env=test 的标签，这样后期就可以基于不同的环境做分析。
[root@prom-node01 ~]# mkdir /etc/prometheus/targets | |
[root@prom-node01 ~]# cat /etc/prometheus/targets/node_exporter.yml | |
- targets: | |
- prom-node01.oldxu.net:9100 | |
- prom-node02.oldxu.net:9100 | |
labels: | |
env: prod | |
- targets: | |
- prom-node03.oldxu.net:9100 | |
labels: | |
env: test |
3、重新加载 Prometheus 配置⽂件
[root@prom-node01 ~]# curl -X POST http://localhost:9090/-/reload |
# 2.3 基于⽂件服务发现验证
1、检查 Prometheus 的 Status->Targets ⻚⾯，验证 node_exporter 是否已经成功纳⼊监控
# 三. Prometheus 基于 Consul 服务发现
# 3.1 Consul 基本介绍
Consul 是⼀个开源的服务发现和配置管理系统，任何服务都可以向 Consul 注册⾃⼰的实例信息（例如 Web 服务器、数据库、各种内部 API 等），并且其他服务可以通过 Consul 查询这些已注册的服务信息。
Prometheus 基于 Consul 的服务发现流程如下：
- 1、当运⾏⼀个服务时，他会将⾃⼰服务的信息（如服务名称、地址、端⼝等。）注册到 consul 中，当服务不再可⽤时，它会从 Consul 中注销。
- 2、 Prometheus 配置基于 consul 的服务发现，那么它会定期向 Consul 查询当前可⽤的服务列表和元数据。
- 3、Prometheus 使⽤从 Consul 获取的服务信息，来构建⽬标 URL，然后对这些 URL 进⾏数据采集，以监控服务的运⾏状况。
- 4、如果某个服务在 Consul 中被标记为不健康或被注销，Prometheus 会⾃动将这个服务从监控⽬标列表中移除，确保监控⽬标的准确性。
# 3.2 安装 Consul 服务
1、访问 consul 官⽅下载地址 https://www.consul.io/downloads/ ，下载 consul ⾄ prom-node05.oldxu.net 节点
[root@prom-node05 ~]# wget https://releases.hashicorp.com/consul/1.17.1/consul_1.17.1_linux_amd64.zip |
2、解压 consul
[root@prom-node05 ~]# unzip consul_1.17.1_linux_amd64.zip -d /usr/local/bin/
3、准备 consul 启动⽂件
[root@prom-node05 ~]# cat /usr/lib/systemd/system/consul.service | |
[Unit] | |
Description=Consul Service Discovery Agent | |
Documentation=https://www.consul.io/ | |
After=network-online.target | |
Wants=network-online.target | |
[Service] | |
Type=simple | |
User=root | |
Group=root | |
ExecStart=/usr/local/bin/consul agent -server -ui \ | |
-node=consul-server \ | |
-bootstrap-expect=1 \ | |
-data-dir=/var/lib/consul \ | |
-bind=192.168.40.225 \ | |
-client=0.0.0.0 | |
Restart=on-failure | |
[Install] | |
WantedBy=multi-user.target | |
[root@prom-node05 ~]# systemctl daemon-reload | |
[root@prom-node05 ~]# systemctl start consul && systemctl enable consul |
agent：执⾏的命令，各参数含义：
- -server ：表示节点是 server 类型
- -ui ：启⽤ consul 的 web ⻚⾯管理
- -node ：节点名称
- -bootstrap-expect ：表示集群中有⼏个 server 节点进⾏ Leader 选举，单节点集群，就为 1
- -data-dir ：数据⽬录
- -bind ：集群内部通信地址，默认是 0.0.0.0
- -client ：客户端地址，默认是 127.0.0.1
4、访问 consul 的 UI ⻚⾯，通过 http://IP:8500
# 3.3 注册实例⾄ Consul
1、注册节点信息⾄ Consul
# node01 | |
[root@prom-node05 ~]# curl -X PUT --data '{ | |
"Name": "node_exporter", | |
"ID": "node01", | |
"Address": "prom-node01.oldxu.net", | |
"Port": 9100, | |
"Tags": ["shanghai","prod"], | |
"Checks": [{ | |
"HTTP": "http://prom-node01.oldxu.net:9100/metrics", | |
"Interval": "5s" | |
}] | |
}' http://localhost:8500/v1/agent/service/register | |
# node02 | |
[root@prom-node05 ~]# curl -X PUT --data '{ | |
"Name": "node_exporter", | |
"ID": "node02", | |
"Address": "prom-node02.oldxu.net", | |
"Port": 9100, | |
"Tags": ["shanghai","prod"], | |
"Checks": [{ | |
"HTTP": "http://prom-node02.oldxu.net:9100/metrics", | |
"Interval": "5s" | |
}] | |
}' http://localhost:8500/v1/agent/service/register | |
# node03 | |
[root@prom-node05 ~]# curl -X PUT --data '{ | |
"Name": "node_exporter", | |
"ID": "node03", | |
"Address": "prom-node03.oldxu.net", | |
"Port": 9100, | |
"Tags": ["beijing","test"], | |
"Checks": [{ | |
"HTTP": "http://prom-node03.oldxu.net:9100/metrics", | |
"Interval": "5s" | |
}] | |
}' http://localhost:8500/v1/agent/service/register |
2、检查注册的节点信息
3、如何注销对应实例的注册信息
curl --request PUT http://localhost:8500/v1/agent/service/deregister/<ID_Name> |
# 3.4 配置 Prometheus
1、配置 Prometheus，添加⼀个名为 consul_nodes 的 Job，并使⽤ Consul 进⾏服务发现，步骤如下
[root@prom-node01 ~]# vim /etc/prometheus/prometheus.yml | |
scrape_configs: | |
- job_name: "consul_nodes" | |
consul_sd_configs: | |
- server: "prom-node05.oldxu.net:8500" | |
#services: ["node_exporter"] # 限定仅从 Consul 的 node_exporter 这个 Service 发现实例信息（可不配置） |
2、重新加载 Prometheus 配置⽂件
[root@prom-node01 ~]# curl -X POST http://localhost:9090/-/reload |
3、检查 Prometheus 的 Status->Targets ⻚⾯，验证 consul_nodes 是否已经成功纳⼊监控
4、验证，添加和删除 consul 中的实例，检查 Prometheus 是否会⾃动完成更新。
curl --request PUT http://localhost:8500/v1/agent/service/deregister/node03 |
# 四。服务发现与 Relabeling
# 4.1 为何需要 Relabel
通过前⾯的演示，我们知道 Prometheus 连接 consul，就能⾃动地从 Consul 服务中获取已注册的实例信息，并对这些实例进⾏监控。后续 Prometheus 还会周期性的从 Consul 中获取最新的实例信息，已便能，动态的更新监控的⽬标列表。
但对于线上环境，我们通常将对服务器集群分成不同的环境，⽐如⽣产环境（prod）和测试环境（test）。这种划分就带来了⼏个额外的需求：
- 1、需要确保从每个实例抓取的监控指标都能够清晰地表明它所属的环境。这就需要在指标的标签中添加 env=prod 或 env=test 来实现，只有这样，我们才能对不同的环境进⾏分析。
- 2、研发团队通常只关注测试环境的实例。因此我们需要⼀种⽅式来过滤实例，只将测试环境的实例提供给研发团队。
- 3、如果我们为每个团队配置了独⽴的 Prometheus 服务器，我们就需要确保每个服务器只收集与该团队相关环境的监控实例。这意味着，我们需要在服务发现过程中进⾏配置，以便不同的 Prometheus 抓取不同环境的实例。。
⾯对以上这些场景的需求，我们就希望 Prometheus 能够根据特定的（规则）来筛选⽬标实例、或者是给⽬标实例添加不同维度的标签。具体来说，我们需要在抓取⽬标实例的指标之前，为⽬标实例增加 “标签” 来识别不同的环境。此外，我们还可以只抓取那些能匹配到 “特定标签” 的实例，⽽那些没有匹配到特定标签的实例则直接排除掉，不进⾏抓取。为了满⾜这种需求，Prometheus 设计了⼀个强⼤的特性，叫标签重写，也被称为 Relabel。
# 4.2 Relabel ⼯作逻辑
relabel 它可以在抓取⽬标实例数据之前，可以对⽬标实例的标签进⾏ “灵活的改写”。借助 Relabel，⽤户就可以⾃⾏定义复杂的 “标签选择逻辑”，从⽽精准的控制哪些实例应当被监控，哪些实例应当被排除。例如，我们可以设置规则，仅抓取带有 env=prod 标签的⽬标实例数据，⽽那些不含此标签的实例则忽略掉 。
在 Prometheus 中，每个被监控的⽬标实例都有⼀组默认的元数据标签（Metadata），这些标签详细记录了⽬标实例的⼀些基本信息
- _address_ ：记录了当前被监控⽬标实例的⽹络地址，通常由主机名和端⼝号。Prometheus 抓取该⽬标的指标时会使⽤这个地址。
- _scheme_ ：记录了抓取⽬标实例指标时应使⽤的 HTTP 协议类型，通常是 http 或 https。
- ·_metrics_path_ ：记录了 Prometheus 抓取指标数据时会通过⽬标实例的那个 URI 路径获取指标数据。默认路径通常是 /metrics。
- __param_
: 这是⼀种特殊的标签格式，⽤于在抓取时传递给⽬标服务的特定 HTTP 请求参数。 是请求参数的名称。
这些以 (双下划线) 开头的，都属于特殊标签，它们主要⽤于内部处理，通常不会出现在采集的指标标签中。不过，默认的 Prometheus 会为采集到的每⼀个实例⾃动添加⼀个 instance 标签，⽽这个 instance 标签的值，其实就是从⽬标实例的内部 address__ 标签那⾥继承来的。这其实是⼀个标签重写的过程，也就是在数据采集之前，已经对⽬标实例的内部标签进⾏了⼀次 Relabel 操作。（Relabel 后会将所有__开头的标签从标签集中删除。）
因此，Relabel 功能提供了强⼤的标签定制能⼒，它允许我们对默认提供的元数据标签进⾏定制。我们可以更改标签、增加新的标签，或者保留那些满⾜特定条件标签的实例。从⽽使监控的⽬标实例更符合我们的具体需求。
# 4.3 Relabel 配置示例
在 Prometheus 的配置中，relabel_configs 提供了强⼤的标签重写功能，允许对监控数据中的标签进⾏定制处理。每个 relabel_configs 规则都包含了如下⼏个关键参数，它们共同决定了如何处理标签。以下是⼀个 relabel_configs 的配置示例，它展示了如何提取源标签，进⾏匹配，并根据匹配结果决定保留还是丢弃⽬标
scrape_configs: | |
- job_name: 'my_job' | |
# ... 其他配置 ... | |
relabel_configs: | |
# 规则 1: 重写实例标签的值 | |
- source_labels: [__address__] # 使⽤ __address__ 作为源标签，它通常包含⽬标的 IP 地址和端⼝ | |
regex: "(.*):10250" # 正则表达式匹配以 :10250 结尾的地址 | |
replacement: "${1}:9100" # 将匹配到的地址的端⼝替换为 9100 | |
action: replace # 动作，替换 | |
target_label: instance # 替换后的地址赋值到 instance 标签 | |
# 规则 2: 保留特定端⼝的⽬标实例 | |
- source_labels: [__address__] # 同样使⽤ __address__ 作为源标签 | |
regex: "(.*):80" # 正则表达式匹配以 :80 结尾的地址 | |
action: "keep" # 如果地址匹配此正则，则保留该实例（不丢弃） | |
# 规则 3: 丢弃特定端⼝的⽬标实例 | |
- source_labels: [__address__] # 再次使⽤ __address__ 作为源标签 | |
regex: "(.*):8080" # 正则表达式匹配以 :8080 结尾的地址 | |
action: "drop" # 如果地址匹配此正则，则丢弃该实例（不抓取对应实例） |
relabel_configs 的配置语法
# 这是⼀个标签列表，其值将被⽤于后续的重标记操作。可以从原始⽬标的标签中选择⼀个或多个标签作为源。 | |
[ source_labels: '[' <labelname> [, ...] ']' ] | |
# 当有多个 source_labels 时，这个参数定义了如何将它们的值合并在⼀起。如果没有指定，默认分隔符为分号 (;) | |
[ separator: <string> | default = ; ] | |
# 正则表达式，⽤于匹配 source_labels 的值。如果没有指定，默认情况匹配任何字符串，即 | |
(.*)。 | |
[ regex: <regex> | default = (.*) ] | |
# 如果正则表达式匹配成功，将通过 replacement 提取对应匹配的值。 如果没有指定，默认替换值为 $1，即匹配到的整个字符串。 | |
[ replacement: <string> | default = $1 ] | |
# 这定义了如果 regex 成功匹配，应该执⾏什么操作。操作可以是替换 (replace)、保留 (keep)、丢弃 (drop) 等。如果没有指定，默认操作是 replace。 | |
[ action: <relabel_action> | default = replace ] | |
# 当执⾏替换操作时，这个参数定义了应该将对应的值写⼊到哪个标签中（可以是 diy 的⼀个名称） | |
[ target_label: <labelname> ] |
relabel_action 字段⽤于定义重新标记的⾏为，其可⽤取值如下：
替换 replace: ⽤于更改标签的值
- 1、⾸先拼接 source_labels 中指定的所有标签的值。
- 2、然后使⽤ regex 字段提供的正则表达式，对这个拼接后的字符串进⾏匹配。
- 3、如果匹配成功，就将 regex 匹配的结果，通过 “后向引⽤” 的⽅式赋予给 replacement
- 4、最后将 replacement 中保存的值，赋予给 target_label 指定的标签。（可以对原有标签的覆盖，也可以是新创建的标签）
keep、drop：⽤于删除或保留实例
- keep：检查 source_labels 指定的标签，对应的值是否与 regex 匹配。当它们匹配时，这个⽬标实例才会被保留。
- drop：检查 source_labels 指定的标签，对应的值是否与 regex 匹配，当它们匹配时，这个⽬标实例才会被删除。
创建或删除标签
- labelmap：将 regex 对所有的标签名进⾏匹配判定，⽽后将匹配到的标签的值赋给 replacement 字段指定的标签名之上；通常⽤于取出匹配的标签名的⼀部分⽣成新标签；
- labeldrop：将 regex 对所有的标签名进⾏匹配判定，能够匹配到的标签将从该 target 的标签集中删除；
- labelkeep：将 regex 对所有的标签名进⾏匹配判定，不能匹配到的标签将从该 target 的标签集中删除；
注意：要确保在 labeldrop 或 labelkeep 操作后，余下的标签集依然能惟⼀标识该指标
# 五. Relabel 实践案例
Prometheus 从 Consul 中发现端点时，它会获取每个服务实例的元数据标签。以下是⼀些由 Consul 服务发现，提供的元数据标签示例及其⽤途：
| 源标签 | 标签⽤途 |
|---|---|
| __meta_consul_address | Consul 服务的地址。可以⽤来添加⼀个标签，指明服务的地址。 |
| __meta_consul_dc | 表示服务所在的数据中⼼。这可以⽤来创建⼀个标签，以区分不同数据中⼼的指标。 |
| __meta_consul_node | 服务所在的 Consul 节点信息。可以⽤于标识服务属于哪个节点。 |
| __meta_consul_service_address | 服务的访问地址。 |
| __meta_consul_service_id | 服务的唯⼀ ID。这个标签可以⽤来唯⼀标识服务实例。 |
| __meta_consul_service_port | 服务的端⼝。 |
| __meta_consul_service | 服务的名称。这个标签可以⽤来显示服务的友好名称。 |
| __meta_consul_tags | 服务的标签信息。这些标签可以⽤来添加额外的上下⽂信息，⽐如环境、版本号等。 |
# 5.1 标签值替换 replace
场景 1，对 Consul 注册的服务实例添加不同维度的标签。具体来说
- 1、从服务实例的 __meta_consul_tags 中提取地域信息，然后将对应的值赋予给 region 标签。
- 2、从服务实例的 __meta_consul_tags 中提取环境信息，然后将对应的值赋予给 env 标签。
这样做有助于后续的指标分类，还能便于我们基于环境（如⽣产环境、测试环境）进⾏服务实例的筛选。
1、配置 Prometheus
[root@prom-node01 ~]# vim /etc/prometheus/prometheus.yml | |
scrape_configs: | |
- job_name: "consul_nodes" | |
consul_sd_configs: | |
- server: "prom-node05.oldxu.net:8500" | |
relabel_configs: | |
- source_labels: [__meta_consul_tags] | |
regex: '.*(shanghai|beijing).*' | |
replacement: $1 | |
action: replace | |
target_label: region | |
- source_labels: [__meta_consul_tags] | |
regex: '.*(prod|test).*' | |
replacement: $1 | |
action: replace | |
target_label: env | |
[root@prom-node01 ~]# curl -X POST http://localhost:9090/-/reload |
2、验证结果
3、通过指标查询 ，会发现在每个指标上都附着了对应的标签
node_load1{instance="prom-node01.oldxu.net:9100", job="consul_nodes", env="prod", region="shanghai"} 0.01 | |
node_load1{instance="prom-node02.oldxu.net:9100", job="consul_nodes", env="prod", region="shanghai"} 0.08 | |
node_load1{instance="prom-node03.oldxu.net:9100", job="consul_nodes", env="test", region="beijing"} 0 |
# 5.2 保留实例 keep
场景 1，保留从 Consul 服务中获取的所有实例，但端⼝是 9100 的节点。
1、编辑 Prometheus 配置⽂件
[root@prom-node01 ~]# vim /etc/prometheus/prometheus.yml | |
scrape_configs: | |
- job_name: "consul_nodes" | |
consul_sd_configs: | |
- server: "prom-node05.oldxu.net:8500" | |
relabel_configs: | |
- source_labels: [__meta_consul_tags] | |
regex: '.*(shanghai|beijing).*' | |
target_label: region | |
- source_labels: [__meta_consul_tags] | |
regex: '.*(prod|test).*' | |
target_label: env | |
- source_labels: [__scheme__,__address__,__metrics_path__] | |
regex: '(http|https)(.*)' | |
replacement: "${1}://${2}" | |
action: replace | |
separator: "" #将默认分割符号；更改为空 | |
target_label: endpoint | |
# 仅保留地址为 9100 的节点 | |
- source_labels: [__address__] | |
regex: (.*):9100 | |
replacement: $1 | |
action: keep | |
[root@prom-node01 ~]# curl -X POST http://localhost:9090/-/reload |
2、验证结果
场景 2，添加⼀个新的 consul_node_prod 的 Job，并配置 Prometheus 只抓取那些在 __meta_consul_tags 标签中被标记为 prod 的服务实例。并丢弃其他所有⾮ Prod 的实例。这样运维团队就可以专注于监控⽣产环境的指标数据。
1、修改 Prometheus 配置⽂件
[root@prom-node01 ~]# vim /etc/prometheus/prometheus.yml | |
scrape_configs: | |
- job_name: "consul_nodes_prod" | |
consul_sd_configs: | |
- server: "prom-node05.oldxu.net:8500" | |
relabel_configs: | |
- source_labels: [__meta_consul_tags] | |
regex: ".*(prod|test).*" | |
replacement: $1 | |
action: replace | |
target_label: env | |
- source_labels: [env] | |
regex: "prod" | |
replacement: $1 | |
action: keep |
2、验证结果
# 5.3 删除实例 drop
场景 1，将 consul 服务中注册的 8300 端⼝的实例，直接丢弃掉。
1、配置 Prometheus，匹配源标签 address ，将节点为 8300 的直接丢弃；
[root@prom-node01 ~]# vim /etc/prometheus/prometheus.yml | |
scrape_configs: | |
- job_name: "node_exporter" | |
consul_sd_configs: | |
- server: "prom-node05.oldxu.net:8500" | |
relabel_configs: | |
- source_labels: [__address__] | |
regex: (.*):8300 | |
replacement: $1 | |
action: drop |
2、验证结果
场景 2，添加⼀个新的 consul_node_test 的 Job，并配置 Prometheus 只抓取那些在 __meta_consul_tags 标签中被标记为 test 的服务实例。并丢弃其他所有⾮ test 的实例。这样研发团队就可以专注于监控 test 环境实例的指标数据。
1、编辑 Prometheus 配置⽂件
[root@prom-node01 ~]# vim /etc/prometheus/prometheus.yml | |
scrape_configs: | |
- job_name: "consul_nodes_test" | |
consul_sd_configs: | |
- server: "prom-node05.oldxu.net:8500" | |
relabel_configs: | |
- source_labels: [__meta_consul_tags] | |
regex: ".*(prod|test).*" | |
replacement: $1 | |
action: replace | |
target_label: env | |
# env=prod 的删除就相当于只有 test 环境保留 （前提是只有两个环境，不然还是建议使⽤ keep 直接保留所需的环境） | |
- source_labels: [env] | |
regex: "prod" | |
replacement: $1 | |
action: drop |
2、检查结果
# 5.4 标签值映射 labelmap
场景 1，⽤ regex 正则表达式，对所有实例的标签进⾏匹配，匹配成功的标签将重命名，新标签名称由匹配到标签名，加上⼀个后缀 _name 构成，⽽ “标签值” 保持不变。
1、编辑 Prometheus 配置
[root@prom-node01 ~]# vim /etc/prometheus/prometheus.yml | |
scrape_configs: | |
- job_name: "consul_nodes_test" | |
consul_sd_configs: | |
- server: "prom-node05.oldxu.net:8500" | |
relabel_configs: | |
- source_labels: [__meta_consul_tags] | |
regex: ".*(prod|test).*" | |
replacement: $1 | |
action: replace | |
target_label: env | |
- source_labels: [env] | |
regex: "prod" | |
replacement: $1 | |
action: drop | |
- source_labels: [__address__] | |
regex: "(.*):9100" | |
replacement: $1 | |
action: keep | |
- regex: "(job|env)" | |
replacement: "${1}_name" | |
action: labelmap |
2、验证结果
场景 2，在使⽤ Consul 服务发现时，将所有以 __meta_consul_service_ 为前缀的标签提取出来，并⽣成新的标签，但 “标签值” 任然不变。
1、编辑 Prometheus 配置
[root@prom-node01 ~]# vim /etc/prometheus/prometheus.yml | |
scrape_configs: | |
- job_name: "consul_nodes_test" | |
consul_sd_configs: | |
- server: "prom-node05.oldxu.net:8500" | |
relabel_configs: | |
- source_labels: [__meta_consul_tags] | |
regex: ".*(prod|test).*" | |
target_label: env | |
- source_labels: [env] | |
regex: "prod" | |
action: drop | |
- source_labels: [__address__] | |
regex: "(.*):9100" | |
action: keep | |
- regex: "(job|env)" | |
replacement: "${1}_name" | |
action: labelmap | |
- regex: "__meta_consul_service_(.*)" | |
replacement: "consul_${1}" # 在字段前⾯额外添加⼀个 consul_字符串 | |
action: labelmap |
2、验证结果
