监控-Prometheus04-服务发现

  • Prometheus服务发现能够自动化检测分类，并且能够识别新目标和变更目标。也就是说，可以在容器平台或云平台中，自动发现并监控新目标或变更目标，动态进行数据采集和处理。
  • Prometheus的服务发现的类型有：
    • 基于文件的服务发现
    • 基于DNS的服务发现
    • 基于API的服务发现：Kubernetes、Consul、Azure...
  • 服务发现的说明文档：https://prometheus.io/docs/prometheus/latest/configuration/configuration/

1、基于文件的服务发现

  • 静态配置：通过修改prometheus.yml文件，将targets加入到监控系统（上一节使用的方式）。这种方式比较适用于只有少量主机或应用程序。
  • 基于文件的服务发现只是比静态配置提高了的配置功能。
    • 在Prometheus所支持的大部分服务发现方式中，这种方式不依赖第三方服务，是比较通用的服务发现方式。
    • 文件可以是JSON或YAML格式的文件，但是文件扩展名必须是.json或.yaml。
    • 每个文件中可以包含目标列表，定义格式和静态配置中的是一致的。
    • Prometheus会定时从已经添加的JSON或YAML格式文件中读取新的targets信息。
  • 基于文件的服务发现仍然是对配置文件进行修改的操作。如果你的应用环境中部署了配置管理工具，例如Ansible、SaltStack、Puppet等工具，再或配合CMDB（配置管理数据库）就可以使用编写好的模板生成服务器、容器或各类应用服务列表的动态配置文件，然后Prometheus定时刷新重新加载目标文件，最终实现服务自动发现功能。

示例：

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
global:
  scrape_interval: 15s
  evaluation_interval: 15s
alerting:
  alertmanagers:
  - static_configs:
    - targets:
rule_files:
 
scrape_configs:
#静态配置
- job_name: "static_node_exporter"
  static_configs:    #静态配置的关键字
  - targets:
    - 10.1.1.13:9100
    labels:
      "app": "node_exporter"
      "job": "node"

1.1、基础配置

1、基于文件的服务的文件

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
//JSON文件
[
  {
    "targets": [ "<host>", ... ],
    "labels": {
      "<labelname>": "<labelvalue>",
      ...
    }
  },
  ...
]
 
//YAML文件
- targets:
  - <host1>
  - <host2>
  labels:
    <labelname1>: <labelvalue1>
    <labelname2>: <labelvalue2>

2、prometheus.yml配置文件

?
1
2
3
4
5
6
7
//基于文件的服务发现
scrape_configs:
- job_name: <job_name>
  file_sd_configs:                  #基于文件的服务发现的关键字
  - files:
    - <filename_pattern>            #可以是以.json、.yml或.yaml结尾的文件，文件名可以使用*，例如tatgets/*.json
    refresh_interval: <duration>    #（可选的）重新读取文件的刷新间隔。默认60s

1.2、实现基于文件的服务发现

1、添加JSON或YAML文件

  • 这两种文件可以使用一种即可，当然也可以一起使用。
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
//使用JSON文件添加10.1.1.11
]# vim /apps/prometheus/tatgets/node_service_discovery.json
[
  {
    "targets": ["10.1.1.11:9100"],
    "labels": {
      "app": "node_exporter",
      "job": "node"
    }
  }
]
 
//使用YAML文件添加10.1.1.12
]# vim /apps/prometheus/tatgets/node_service_discovery.yaml
- targets:
  - 10.1.1.12:9100
  labels:
    "app": "node_exporter"
    "job": "node"

2、修改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
]# vim /apps/prometheus/prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s
alerting:
  alertmanagers:
  - static_configs:
    - targets:
rule_files:
 
scrape_configs:
#静态配置
- job_name: "static_node_exporter"
  static_configs:
  - targets:
    - 10.1.1.13:9100
    labels:
      "app": "node_exporter"
      "job": "node"
#基于文件的服务发现
- job_name: "file_sd_nodes_exporter"
  file_sd_configs:
  - files:
    - tatgets/*.json
    refresh_interval: 60s
  - files:
    - tatgets/node_service_discovery.yaml
    refresh_interval: 60s

3、重新加载prometheus.yml配置文件

  • 注意，只有在修改prometheus.yml配置文件后，才需要重新加载该文件。若是再向“基于文件的服务发现”的文件中添加target，不需要重新加载prometheus.yml配置文件。
?
1
2
3
4
5
//检查配置文件
promtool check config /apps/prometheus/prometheus.yml
 
//重新加载配置文件
]# kill -HUP PID

2、基于DNS的服务发现

  • 基于DNS的服务发现针对一组DNS域名进行定期查询，以发现待监控的目标
    • 查询时使用的DNS服务器由/etc/resolv.conf文件指定。
    • 该发现机制依赖于A、AAAA和SRV资源记录，且仅支持该类方法，尚不支持RFC6763中的高级DNS发现方式。

2.1、基础配置

?
1
2
3
4
5
6
7
scrape_configs:
- job_name: <job_name>
  dns_sd_configs:                   #关键字
  - names: [<string>, ...]          #DNS资源的名称，例如百度的A记录是www.baidu.com.
    type: <string>                  #（可选的）要执行的DNS查询的类型，可用值有：SRV（默认值）、A、AAAA或MX。
    port: <int>                     #（可选的）当查询类型不是SRV时，必须使用的端口号
    refresh_interval: <duration>    #（可选的）刷新的时间间隔，默认30s

2.2、基于DNS的服务发现

1、解析域名

?
1
2
3
4
5
6
]# dig  www.baidu.com
...
;; ANSWER SECTION:
www.baidu.com.      71  IN  A   36.152.44.96
www.baidu.com.      71  IN  A   36.152.44.95
...

2、修改prometheus.yml配置文件

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
]# vim /apps/prometheus/prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s
alerting:
  alertmanagers:
  - static_configs:
    - targets:
rule_files:
 
scrape_config
#基于DNS的服务发现
- job_name: "DNS_sd_node_exporter"
  dns_sd_configs:
  - names: ["www.baidu.com."]
    type: A
    port: 80
    refresh_interval: 60s

3、重新加载prometheus.yml配置文件

?
1
2
3
4
5
//检查配置文件
promtool check config /apps/prometheus/prometheus.yml
 
//重新加载配置文件
]# kill -HUP PID

3、基于Consul的服务发现（注册中心）

3.1、Consul的基础概念

  • 基于Consul的服务发现是一种使用网络的服务发现机制和配置工具，是使用Go语言开发的，部署安装简单，具有分布式、高可用性和极高的可扩展性。它提供了以下几个关键功能。
    • 服务发现：Consul通过HTTP API和DNS进行服务注册和服务发现。对于外部服务（如SaaS提供者）也可以注册。
    • 健康检查：Consul支持对各类服务运行状态的健康检查工作，能够迅速向管理员告警集群中的任何问题，可以防止将流量路由到问题或故障主机，可动态监视服务运行状况并适当更新服务注册表。
    • 键/值存储：键/值存储可以灵活地进行存储动态配置、功能标记、协调和领导者选举等。简单的HTTP API使其易于在任何地方使用。
    • 多数据中心：Consul支持单一数据中心，可扩展以支持多个数据中心，并且无须复杂的配置。
    • 服务分割：通过自动TLS加密和基于身份的授权实现安全的服务间通信。
  • Consul体系架构如图4-6所示。

  • 从图中可以看到在Consul体系架构中：
    • Client（即客户）端模式是无状态的，它负责将所有RPC转发到Server（即服务器）的代理。Client执行的唯一后台活动是加入到LAN Gossip池。也就是说所有注册到当前节点的服务会被转发到Server中，而自身是不持久化这些信息。虽然这样会有资源开销，但仅仅是消耗少量的网络带宽。
    • Server（即服务器）端模式是具有一组扩展功能的代理，包括参与Raft选举、集群状态维护和响应RPC查询。Server端与其他数据中心交互WAN Gossip，并将查询转发给Server Leader或远程数据中心。它可以持久化所有数据信息到本地，这样就算出现故障，信息也得以保存。Server Leader负责Server间注册信息的同步和各个节点的监控检查工作。
  • LAN Gossip包含位于同一局域网或数据中心的节点。WAN Gossip仅包含Server，这些Server主要位于不同的数据中心，通常通过互联网或广域网进行通信。
  • 依据官方说明可以看到图4-6中有两个数据中心，DATACENTER1和DATACENTER2，这表明Consul是支持多数据中心的。每一个数据中心都是由Server和Client共同组成。官方建议一个数据中心有3～5台Server最佳，这样可以实现可用性和性能二者之间的平衡。因为Server的增加势必会造成一致性（consensus）变慢。对于Client数量是没有限制的，随着业务的增加，Client会很容易地被扩容到成千甚至上万的数量级别。
  • 在每个数据中心中，所有节点都要加入Gossip协议。这样设计有以下目的：
    • 第一，不需要为客户端配置服务器的地址，发现是自动完成的；
    • 第二，检测节点故障的工作不是放在服务器上，而是分布式的，这使得故障检测比心跳机制更具有可扩展性；
    • 第三，可以被用作消息传递层，比如Leader选举事件。
  • RPC（Remote Procedure Call），即远程过程调用协议，是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
  • Raft是一种共识算法，旨在替代Paxos。它通过逻辑分离使其比Paxos更容易理解，并被正式证明是安全的，并提供了一些额外的功能。它提供了一种在计算系统集群中分布状态机的通用方法，在一个特定的任期内，最多只能选举出一名领导者（Leader），确保集群中的每个节点都同意一系列相同的状态转换。
  • Gossip是分布式系统中被广泛使用的协议，协议本身简单且通信性能好，主要用于实现分布式节点或者进程之间的信息交换，最终状态都达成一致。常用于P2P的通信和实现应用层多播。

3.2、Consul安装并启动

1、安装consul

  • 需要在每一个被监控主机或容器上安装Consul。
?
1
2
3
4
5
6
7
8
//下载
]# wget https://releases.hashicorp.com/consul/1.13.2/consul_1.13.2_linux_amd64.zip
 
//创建consul存放目录
]# mkdir -p /apps/consul/{data,conf}
 
//解压
]# unzip consul_1.13.2_linux_amd64.zip -d /apps/consul/

2、启动consul

  • 最简单的使用方法是开发者模式，在本地终端快速创建一个单节点的Consul环境。但是，此种模式不能在线上生产环境中使用，因为它不会持久化任何状态。
  • Consul必须启动agent才可使用，它是运行在Consul集群中每个成员上的守护进程，该进程负责维护集群中成员信息、注册服务、查询响应、运行检查等功能。
  • agent指令是Consul的核心，可以运行为Server或Client模式。
  • 启动consul，开发模式：
?
1
2
//运行开发者模式的consul agent
]# /apps/consul/consul agent -dev -ui -client=0.0.0.0 -bind=10.1.1.11 -config-dir=/apps/consul/conf -data-dir=/apps/consul/data
  • 查看当前consul集群中的所有节点信息
?
1
2
3
]# /apps/consul/consul members
Node         Address         Status  Type    Build   Protocol  DC   Partition  Segment
k8s-master1  10.1.1.11:8301  alive   server  1.13.2  2         dc1  default    <all>
  • Consul运行需要监听至少6个不同的默认端口才能正常工作，这些默认端口使用TCP或UDP协议。
    • 注意，当使用开发者模式在本地终端快速创建一个单节点的Consul环境时，即使用命令行选项-dev模式运行时，默认RPC监听端口为8502 TCP（本来是8400 TCP）。
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
]# netstat -npl | grep consul
//Server RPC端口，用于Client与Server通信或Server与Server通信
tcp        0      0 10.1.1.11:8300          0.0.0.0:*               LISTEN      32767/consul
//用于单个数据中心所有Client问通信
tcp        0      0 10.1.1.11:8301          0.0.0.0:*               LISTEN      32767/consul
udp        0      0 10.1.1.11:8301          0.0.0.0:*                           32767/consul
//用于单个或多个数据中心之间Server信息同步
tcp        0      0 10.1.1.11:8302          0.0.0.0:*               LISTEN      32767/consul
udp        0      0 10.1.1.11:8302          0.0.0.0:*                           32767/consul
//用于API接口或WEB UI访问
tcp6       0      0 :::8500                 :::*                    LISTEN      32767/consul
//所有agent都要使用的端口,用于处理从CLI来的RPC
tcp6       0      0 :::8502                 :::*                    LISTEN      32767/consul
tcp        0      0 10.1.1.11:8502          0.0.0.0:*               LISTEN      25242/consul
//用于解析DNS查询
tcp6       0      0 :::8600                 :::*                    LISTEN      32767/consul
udp6       0      0 :::8600                 :::*                                32767/consul

3.3、Consul服务注册

  • Consul服务注册有两种方法：
    • (1)定义配置文件服务注册方法，即在配置文件中定义服务来进行注册。
    • (2)HTTP API服务注册方法，即在启动后由服务自身通过调用API进行自我注册。
  • 将本地运行的node_exporter注册到Consul服务上。

1、创建JSON格式的配置文件

  • 在配置目录中添加文件
    • -config-dir=/apps/consul/conf
?
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
36
37
38
39
40
41
42
43
44
//定义单个Service
]# vim /apps/consul/conf/node_exporter01.json
{
    "service": {
        "id": "node_exporter",
        "name": "node_exporter",
        "tags": ["nodes01"],
        "address": "10.1.1.11",
        "port": 9100,
        "check": [{
            "http": "http://10.1.1.11:9100/metrics",
            "interval": "5s"
        }]
    }
}
 
//定义多个Services
]# vim /apps/consul/conf/node_exporter.json
{
  "services": [
        {
      "id": "node_exporter01",
      "name": "node_exporter",
      "tags": ["nodes"],
      "address": "10.1.1.13",
      "port": 9100,
      "check": [{
            "http": "http://10.1.1.13:9100/metrics",
            "interval": "5s"
      }]
    },
    {
      "id": "node_exporter02",
      "name": "node_exporter",
      "tags": ["nodes"],
      "address": "10.1.1.12",
      "port": 9100,
      "check": [{
        "http": "http://10.1.1.12:9100/metrics",
        "interval": "5s"
      }]
    }
  ]
}
  • 配置文件内容说明如下：
    • id：服务ID，可选提供项。
    • name：服务名称，必须提供项。
    • tags：服务的标签，自定义的可选提供项，用于区分主节点或辅助节点。
    • address：地址字段，用于指定特定于服务的IP地址。默认情况下，使用agent的IP地址，因而不需要提供这个地址。可以理解为服务注册到Consul使用的IP，服务发现是发现的此IP地址。
    • port：可以简单理解为服务注册到Consul使用的端口，服务发现也是发现address对应的端口。

2、重新加载配置内容

?
1
]# /apps/consul/consul reload

3、通过HTTP API和DNS两种方式进行服务发现

?
1
2
3
4
5
//通过HTTP API进行服务发现
]# curl http://10.1.1.11:8500/v1/catalog/service/node_exporter
 
//通过DNS进行服务发现
]# dig @10.1.1.11 -p 8600 node_exporter.service.consul 

3.4、与Prometheus集成

  • Consul完成服务注册和发现后，维护着整个应用环境中的所有服务信息。此时，通过Prometheus与Consul的交互便可取得上一小节已经注册的node_exporter的信息。

1、修改prometheus.yml配置文件

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
]# vim /apps/prometheus/prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s
alerting:
  alertmanagers:
  - static_configs:
    - targets:
rule_files:
 
scrape_configs:
#基于Consul的服务发现
- job_name: "consul_sd_node_exporter"
  consul_sd_configs:
  - server: 10.1.1.11:8500
    services:               #consul中的service.name
    - node_exporter
    tags:                   #consul中的service.tags。只监控service.name，且有该标签的
    - nodes

3、重新加载prometheus.yml配置文件

?
1
2
3
4
5
//检查配置文件
promtool check config /apps/prometheus/prometheus.yml
 
//重新加载配置文件
]# kill -HUP PID

4、Relabelling（重新打标）

  • 构建基于文件的服务发现
?
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
36
//修改prometheus.yml配置文件
]# vim /apps/prometheus/prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s
alerting:
  alertmanagers:
  - static_configs:
    - targets:
rule_files:
 
scrape_configs:
- job_name: "file_sd_nodes_exporter"
  file_sd_configs:
  - files:
    - tatgets/*.yaml
    refresh_interval: 60s
 
//基于文件的服务发现的yaml文件
]# vim /apps/prometheus/tatgets/node_service_discovery.yaml
- targets:
  - 10.1.1.12:9100
  labels:
    "env": "test_node_exporter"
    "job": "node"
- targets:
  - 10.1.1.13:9100
  labels:
    "env": "dev_node_exporter"
    "job": "node"
 
//检查配置文件
promtool check config /apps/prometheus/prometheus.yml
  
//重新加载配置文件
]# kill -HUP PID
  • 查看target的元数据标签

4.1、重新打标的基础

4.1.1、指标的生命周期

  • Prometheus抓取指标的生命周期：
    • 在每个scrape_interval期间，Prometheus都会检查配置文件中的作业(Job) ，并根据Job的配置生成target列表。
      • 每个target上都有一组元数据（metadata）标签（即原始标签）。可以通过Prometheus Web UI中的targets页面中查看实例的元数据标签。当鼠标移动Labels栏里，可以自动显示默认标签，如图4-12所示。
    • 根据配置文件中的relabel_configs配置，对target进行重新打标，生成target和其标签。
    • 然后，去target抓取指标（会获取exporter的所有指标）。
    • 对抓取到的指标根据配置文件中的metric_relabel_configs配置进行重新打标（即修改、删除、添加标签），存储修改后的指标。

  • relabel_config可以实现的功能（对target生效）：
    • 对服务发现的target进行重新打标（根据元标签进行修改、删除、添加）
    • 过滤服务发现的target，即只监控指定的target。
  • metric_relabel_configs可以实现的功能（对指标生效）：
    • 删除不需要的指标。
    • 删除敏感的或不需要的标签。
    • 修改、添加指标的标签或标签格式。

4.1.2、重新打标基础语法

  • 重新打标基础语法：
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
//重新打标的关键字
scrape_configs:
- job_name: <job_name>
  relabel_configs:                #对target进行重新打标
    [ - <relabel_config> ... ]
  metric_relabel_configs:         #对指标进行重新打标
    [ - <relabel_config> ... ]
 
//<relabel_config>的使用方法
#使用现有标签的值。可以指定多个标签，使用separator指定的连接符（默认是分号“;”）将这些标签的值连接成一个字符串（以后就叫做source_labels字符串）
[ source_labels: '[' <labelname> [, ...] ']' ]
[ separator: <string> | default = ; ]
#使用正则表达式从上面的标签值（多个标签值连接成的字符串）中获取一个子串。默认是整个字符串。可以使用正则表达式捕获组。
[ regex: <regex> | default = (.*) ]
#如果正则表达式匹配，则对其执行正则表达式替换。可以使用正则表达式捕获组。
[ replacement: <string> | default = $1 ]
#将上面获取的子串赋给新的标签（也可以是现有的标签，会覆盖其值）。
[ target_label: <labelname> ]
#指定正则表达式匹配执行的操作
[ action: <relabel_action> | default = replace ]
#采用源标签值的散列的模数。
[ modulus: <int> ]
  • <regex>：是任何有效的正则表达式。正则表达式锚定在两端。要取消正则表达式的锚定，使用.*<regex>.*。
    • replace、keep、drop、labelmap、labeldrop和labelkeep操作都需要使用它。
  • <relabel_action>：要进行的操作。
    • 替换标签
      • replace：将replacement赋给target_label。如果regex（正则表达式）不匹配，则不进行替换。
      • hashmod：将source_labels字符串进行hash，作为target_label的值。
      • lowercase：将source_label的字符串转化为小写。
      • uppercase：将source_label的字符串转化为大写。
    • 删除targets
      • keep：删除regex不能匹配source_labels字符串的targets。
      • drop：删除regex能匹配source_labels字符串的targets。
    • 创建或删除标签
      • labelmap：使用regex对所有的标签名（不仅仅是source_labels中指定的）进行匹配判定，然后将匹配到的标签的值赋给replacement指定的新标签。（修改标签名，但标签值不变）
      • labeldrop：使用regex对所有的标签名进行匹配判定，任何匹配的标签都将从标签集中删除。
      • labelkeep：使用regex对所有的标签名进行匹配判定，任何不匹配的标签都将从标签集中删除。

4.2、对target进行重新打标

  • Target的内置标签以双下划线“__”开头。在默认情况下，被加载的Target包含以下元数据标签：
    • __address__：当前目标实例的访问地址<host>:<port>。
    • __metrics_path__：抓取目标指标的访问路径。
    • __scheme__：抓取目标指标时的协议：http或https协议。
    • __param_<name>：抓取目标指标时，使用的请求参数。
    • 其中，instance标签的值与__address__相对应，这里发生了一次标签重写处理。

示例：

?
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
scrape_configs:
- job_name: "file_sd_nodes_exporter"
  relabel_configs:
#如果该target的几个标签的source_labels字符串可以被regex匹配，就添加一个新的标签endpoint
  - source_labels:              #将三个标签的值直接拼接起来得到"http10.1.1.12:9100/metrics"
    - __scheme__
    - __address__
    - __metrics_path__
    separator: ""
    regex: (http|https)(.*)     #使用regex匹配source_labels字符串，得到(http)(10.1.1.12:9100/metrics)
    replacement: ${1}://${2}    #使用捕获组拼接，得到"http://10.1.1.12:9100/metrics"
    target_label: endpoint      #将捕获组拼接的值赋给标签名endpoint，得到endpoint="http://10.1.1.12:9100/metrics"
    action: replace             #替换
#添加一个新的标签名"(en.*)_name"
  - regex: (en.*)               #使用regex匹配标签名
    replacement: ${1}_name
    action: labelmap
#删除掉标签名是(en.*)的标签
  - regex: (en.*)               #使用regex匹配标签名
    action: labeldrop
#如果标签env的值可以被(test.*)匹配，就过掉该target
  - source_labels:
    - env
    regex: (test.*)             #使用regex匹配source_labels字符串
    action: drop

4.2.1、添加一个标签

  • 使用重新打标机制，给target添加一个新的标签endpoint="http://10.1.1.12:9100/metrics"。

1、修改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
//修改prometheus.yml配置文件
]# vim /apps/prometheus/prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s
alerting:
  alertmanagers:
  - static_configs:
    - targets:
rule_files:
 
scrape_configs:
- job_name: "file_sd_nodes_exporter"
  file_sd_configs:
  - files:
    - tatgets/*.yaml
    refresh_interval: 60s
  relabel_configs:
  - source_labels:              #将三个标签的值直接拼接起来得到"http10.1.1.12:9100/metrics"
    - __scheme__
    - __address__
    - __metrics_path__
    separator: ""
    regex: (http|https)(.*)     #使用正则匹配，得到(http)(10.1.1.12:9100/metrics)
    replacement: ${1}://${2}    #使用捕获组拼接，得到"http://10.1.1.12:9100/metrics"
    target_label: endpoint      #将捕获组拼接的值赋给标签名endpoint，得到endpoint="http://10.1.1.12:9100/metrics"
    action: replace             #替换

2、重新加载prometheus.yml配置文件

?
1
2
3
4
5
//检查配置文件
promtool check config /apps/prometheus/prometheus.yml
  
//重新加载配置文件
]# kill -HUP PID

3、查看新添加的标签

  • 重启Prometheus或热加载配置后，通过浏览器查看Prometheus Web UI中的信息，可以看到新标签endpoint已经被添加（和图4-12对比），如图4-14所示。

4.2.3、过滤target

  • 使用重新打标机制过滤掉target，如果标签env的值可以被(test.*)匹配，就过掉该target。

1、修改prometheus.yml配置文件

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
//修改prometheus.yml配置文件
]# vim /apps/prometheus/prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s
alerting:
  alertmanagers:
  - static_configs:
    - targets:
rule_files:
 
scrape_configs:
- job_name: "file_sd_nodes_exporter"
  file_sd_configs:
  - files:
    - tatgets/*.yaml
    refresh_interval: 60s
  relabel_configs:
  - source_labels:
    - env
    regex: (test.*)
    action: drop

2、重新加载prometheus.yml配置文件

?
1
2
3
4
5
//检查配置文件
promtool check config /apps/prometheus/prometheus.yml
  
//重新加载配置文件
]# kill -HUP PID

3、查看target

  • 重启Prometheus或热加载配置后，通过浏览器查看Prometheus Web UI中的信息，可以看到regex: (test.*)匹配到的target被过滤掉了（和图4-12对比），如图4-16所示。

4.3、对指标进行重新打标

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
scrape_configs:
- job_name: "file_sd_nodes_exporter"
  metric_relabel_configs:
#如果该指标的标签__name__的值可以被(.*info.*)匹配，就过掉该指标（删除指标）
  - source_labels:
    - __name__
    regex: (.*info.*)           #使用regex匹配source_labels字符串。指标名称本身也是名为__name__的标签。
    action: drop
#删除掉标签名是(cp.*)的标签
  - regex: (cp.*)               #使用regex匹配标签名
    action: labeldrop
#添加一个新的标签名"(cp.*)_name"
  - regex: (cp.*)               #使用regex匹配标签名
    replacement: ${1}_name
    action: labelmap
  • 注意，更改或添加标签会创建新的指标。
    • 应该明确地使用各个标签，并尽可能保持不变，以避免创建出一个动态的数据环境。
    • 标签是时间序列的唯一性约束，删除标签并导致时间序列重复时，可能会导致系统出现问题。
?
1
#                                                                                                                                        #
posted @   麦恒  阅读(312)  评论(0)  编辑  收藏  举报
相关博文：
·  监控-Prometheus02-安装并启动
·  监控-Prometheus09-监控Kubernetes
·  prometheus服务发现
·  Prometheus学习
·  prometheus服务发现
阅读排行：
· TypeScript + Deepseek 打造卜卦网站：技术与玄学的结合
· Manus的开源复刻OpenManus初探
· .NET Core 中如何实现缓存的预热？
· 三行代码完成国际化适配，妙~啊~
· 阿里巴巴 QwQ-32B真的超越了 DeepSeek R-1吗？
点击右上角即可分享
微信分享提示
SQL AI 助手

目录导航