Prometheus运维监控平台之服务发现配置、标签及监控规则编写(二)

系列文章目录

运维监控平台组件介绍及RPM包构建

前言

在第一篇文章中，主要针对运维监控平台组件的介绍及通过fpm工具对二进制安装的组件进行RPM包构建,让大家对整个运维监控平台从概念、安装部署有一个大致的认知。但是在企业环境中仅仅了解概念和安装部署是不够的，随着对技术的深入了解，还得学会prometheus如何监控某一个指标，并且这个指标怎么设置监控规则，只有当监控的指标值超过监控规则设置的阈值后，才会产生一条原始的告警。那么问题就来了，怎么配置监控项以及怎么设置监控规则就是本篇文章的核心思想。接下来，闲话少说开始实战。

一、服务发现机制

1.服务发现概述

prometheus通常是基于pull模式拉取监控数据,首先要能够发现需要监控的目标对象target,但随着容器时代的发展所有的监控对象都在动态变化。
而对于prometheus而言解决方案是引入一个中间代理人(即服务注册中心),这个代理人掌握着当前所有监控目标的访问信息，
而prometheus只需要向这个代理人询问有哪些监控目标即可，这种模式被称为服务发现。

prometheus核心功能包括服务发现、数据采集、数据存储。
从上图可以看到服务发现部分负责发现需要监控的目标采集点信息(即prometheus.yml中的target)
数据采集部分从服务发现中订阅发现到的信息,获取到target信息后(信息包含协议、主机、端口、请求路径、请求参数等)，将这些信息构建出一个http request请求。
然后prometheus 定时通过pull http协议不断的去目标采集点(target)拉取监控样本数据，最后将采集到监控数据交由TSDB时序数据库进行数据存储，

2.prometheus常用的服务发现协议

目前prometheus支持的服务发现协议高达二十多种,下方列出常见的几种

Prometheus 支持的多种服务发现机制:
	#Prometheus数据源的配置主要分为静态配置和动态发现, 常用的为以下几类:
1）static_configs: #静态服务发现
2）file_sd_configs: #文件服务发现
3）dns_sd_configs: DNS #服务发现
4）kubernetes_sd_configs: #Kubernetes 服务发现
5）consul_sd_configs: Consul #consul服务发现

3.服务发现原理分析

如上图所示,prometheus服务发现机制大致涉及到三部分:
1、配置解析处理: 
	主要将prometheus.yml文件中配置的scrape_configs部分中的job_name生成对应的Discovery服务,
	不同的服务发现协议都会有自己的服务发现方式。
	根据自身的发现逻辑去发现target，并将其放入到targer容器中

2、discoveryManager组件:
	这个组件内部有个定时周期触发任务,默认每5秒检查一下target容器,如果有变更则将targets容器中target信息放入到syncCh通道中

3、scrape组件:
	这个组件会监听syncCh通道,这样需要监控的targets信息就会传递给scrape组件,然后将target纳入到监控开始采集监控指标

promethues.yml结合上述描述

二、服务发现配置示例

1.静态服务发现配置示例

当监控目标少的时候可以使用静态监控服务发现

scrape_configs:
  - job_name: "prometheus"               #监控指标名称
    scrape_interval: 5s                  #定时采集周期任务间隔时间
    static_configs:                      #静态服务发现标志
      - targets: ["localhost:9090"] #监控目标

当在prometheus.yml文件中添加了如上配置后,打开prometheus Web-->Status-->Targets如下所示

2.基于consul服务发现配置示例

当监控指标多的时候，适用于consul服务发现，减少人工手动配置

scrape_configs:
  - job_name: "consul-prometheus"
    consul_sd_configs:                                       #基于consul服务发现标志
    - server: 'localhost:8500'                               #consulip和端口
      token: "a0de7f26-127b-cd67-f01e-477c212d7c48"          #consul的ACL认证token
    relabel_configs:                                         #标签转换
      - source_labels: ['__meta_consul_service']
        regex: .*monitor.*
        action: keep
      - source_labels: ['__meta_consul_service_address']
        target_label: ip
      - source_labels: ['__meta_consul_service_port']
        target_label: port

监控指标注册到consul后的示例.具体的注册方式后续会有文章说明

当在prometheus.yml文件中添加了如上配置后,打开prometheus Web-->Status-->Targets如下所示

三、监控指标标签

1.指标抓取生命周期

1、Prometheus 在每个 scrape_interval 期间都会检测执行的 job，这些 job 会根据指定的服务发现配置生成 target 列表

2、服务发现会返回一个 target 列表，其中包含一组以 __meta_ 为开头的元数据的标签；

3、服务发现还会根据目标配置来设置其他标签，这些标签带有 __ 前缀和后缀，
	包括 __scheme__ 、__address__ 、和 __metrics_path__ ，分别保存有 target 支持使用的协议、target 的地址及指标的 uri
	 路径（默认为 metric），这些 target 列表和标签会返回给 Prometheus，其中一些标签也可以在配置中被覆盖。
	配置标签会在抓取的生命周期中被重复利用以生成其他标签，比如指标上的 instance 标签的默认值就来自于 __address__ 标签的值。

4、Prometheus 对发现的各个目标提供了重新打标的机会，可以在 job 配置段的 relabel_configs 中进行配置。
	通常用于实现过滤 target 和将元数据标签中的信息附加到指标的标签上。

5、在重新打标之后便会对指标数据进行抓取及指标数据返回的过程。
	收到的指标数据在保存之前，还允许用户在 metric_relabel_configs 配置段中对指标数据重新打标并对其进行过滤。通常用于删除不需要的指标、在指标中删除敏感或不需要的标签以及添加、编辑或者修改指标的标签值或标签格式。

2.标签的作用

Prometheus中存储的数据为时间序列，是由Metric的名字和一系列的标签(键值对)唯一标识的,不同的标签代表不同的时间序列，即通过指定标签查询指定数据。
不同的标签代表不同的时间序列，即通过指定标签查询指定数据。
指标+标签实现了查询条件的作用，可以指定不同的标签过滤不同的数据.

3.标签分类

3.1.静态服务发现metadata标签示例

metadata标签也称元数据标签，如下图示例

#在promethues.yml中配置一个如下的不包含任何标签的采集任务
  - job_name: tcp_connect
    metrics_path: /probe
    params:
      module: [tcp_connect]
    static_configs:
      - targets:
        - 192.168.56.131:9273
        - 192.168.56.132:9273

打开prometheus Web查看元数据标签

如上元数据标签所示:
	__address__: "当前Target实例的访问地址<host>:<port>"
	__scheme__: "采集目标服务访问地址的HTTP Scheme，HTTP或者HTTPS"
	__metrics_path__: "采集目标服务访问地址的访问路径"
	__parm_module: "存储来自配置中的参数的值"
	__scrape_interval__: "采集间隔"
	__scrape_timeout__: "采集超时时间"
	job: "采集任务名称"

3.2.基于consul动态服务发现metadata标签

如果了解go语言，可以参考prometheus源码中的discoveryLabels发现这部分

#通过api获取标签
[root@python2 prometheus]# curl -s http://localhost:9090/api/v1/targets  -uadmin:QAZXCFRF
{
    "status": "success",
    "data": {
        "activeTargets": [
            {
                "discoveredLabels": {
                    "__address__": "192.168.56.131:9273",
                    "__meta_consul_address": "192.168.56.131",
                    "__meta_consul_dc": "prod",
                    "__meta_consul_health": "passing",
                    "__meta_consul_node": "consul-node",
                    "__meta_consul_service": "monitor_agent",
                    "__meta_consul_service_address": "192.168.56.131",
                    "__meta_consul_service_id": "telegraf-192.168.56.131-9273",
                    "__meta_consul_service_metadata_monitorType": "monitor_agent",
                    "__meta_consul_service_metadata_organization": "运维监控平台",
                    "__meta_consul_service_metadata_project": "监控agent组件",
                    "__meta_consul_service_metadata_version": "v1.22.4",
                    "__meta_consul_service_port": "9273",
                    "__meta_consul_tags": ",telegraf,",
                    "__metrics_path__": "/metrics",
                    "__scheme__": "http",
                    "__scrape_interval__": "15s",
                    "__scrape_timeout__": "10s",
                    "job": "consul-prometheus"
                },
                "labels": {
                    "instance": "192.168.56.131:9273",
                    "ip": "192.168.56.131",
                    "job": "consul-prometheus",
                    "port": "9273"
                },
                "scrapePool": "consul-prometheus",
                "scrapeUrl": "http://192.168.56.131:9273/metrics",
                "globalUrl": "http://192.168.56.131:9273/metrics",
                "lastError": "",
                "lastScrape": "2024-10-16T17:59:53.954209636+08:00",
                "lastScrapeDuration": 0.003238111,
                "health": "up",
                "scrapeInterval": "15s",
                "scrapeTimeout": "10s"
            }
            ....
 }

"__address__": "192.168.56.131:9273",          #当前Target实例的地址<host>:<port>
"__meta_consul_address": "192.168.56.131",     #consul地址
"__meta_consul_dc": "prod",	                   #consul数据中心名称
"__meta_consul_health": "passing",             #target服务状态
"__meta_consul_node": "consul-node",           #consul名称
"__meta_consul_service": "monitor_agent",      #target在consul中注册的服务名称
"__meta_consul_service_address": "192.168.56.131", #consul地址
"__meta_consul_service_id": "telegraf-192.168.56.131-9273", #target注册到consul中的唯一标识
"__meta_consul_service_metadata_monitorType": "monitor_agent", #在target注册到consul时 自定义的meta
"__meta_consul_service_metadata_organization": "运维监控平台", #在target注册到consul时 自定义的meta
"__meta_consul_service_metadata_project": "监控agent组件", #在target注册到consul时 自定义的meta
"__meta_consul_service_metadata_version": "v1.22.4", #在target注册到consul时 自定义的meta
"__meta_consul_service_port": "9273",  #端口
"__meta_consul_tags": ",telegraf,",  #与服务关联的标签
"__metrics_path__": "/metrics",   #指定 Prometheus 用于抓取指标的路径
"__scheme__": "http",            #指定协议，默认为http
"__scrape_interval__": "15s", #指定抓取的时间间隔
"__scrape_timeout__": "10s", #指定抓取的超时时间
"job": "consul-prometheus" #采集任务名称

注意事项: 以上这些metadata标签只是普罗米修斯去使用,我们不会用该标签去查监控值，同时该标签也不会存储到时序数据库中的，使用promql+metadata标签也是查不出来值的

3.3.自定义标签

自定义标签示例

  - job_name: 'service_http_status'
    metrics_path: /probe
    params:
      module: [http_health]
    static_configs:
      - targets: ['http://192.168.30.52:11000/actuator/health']
        labels:
          organization: '运维监控'
          project: '服务监控'
          servicetype: 'telegraf'

自定义标签作用:
	自定义标签可以实现多维度的查询,标签越多查询的维度越细。

注意事项: 在labels显示中job和instance属于默认内部标签,只有监控到了目标，就会存在这两个标签。

3.4.重新标记标签

重新标记目的:
	为了更好的标识监控指标

重新标记分类:
	relabel_configs: 在采集之前（比如在采集之前重新定义元标签）
	metric_relabel_configs: 在存储之前准备抓取指标数据时，可以使用relabel_configs添加一些标签、也可以只采集特定目标或过滤目标。 
		已经抓取到指标数据时，可以使用metric_relabel_configs做最后的重新标记和过滤。

重新标记标签作用:
	1、动态生成新标签  根据已有的标签生成新标签
	2、过滤采集的Target
	3、删除不需要或者敏感标签
	4、添加新标签

重新标记标签示例

  - job_name: "consul-prometheus"
    consul_sd_configs:
    - server: 'localhost:8500'
      token: "a0de7f26-127b-cd67-f01e-477c212d7c48"
    relabel_configs:                                  #重新标记标签
      - source_labels: ['__meta_consul_service']
        regex: .*monitor.*
        action: keep
      - source_labels: ['__meta_consul_service_address']
        target_label: ip
      - source_labels: ['__meta_consul_service_port']
        target_label: port

3.4.1.relabel原理

1、服务发现的目标，初始状态都是标签集合(model.LabelSet)，这些标签集合是可以被调整的。
2、通过标签调整操作，产生不同的行为 (Action) 变化，进而控制采集行为
这就是 relabel 的原理，目前的 relabel 根据执行结果，可以分为两大类，分别是标签转换和采集控制。
标签转换: 将服务发现的内部标签，进行提取、修改和取消的操作，只影响对 Target 采集结果的标签变化。
采集控制: 根据标签匹配，将采集的 Target 进行保留或丢弃，会影响对 Target 的采集请求。

3.4.2.relabel_configs语法及示例

relabel_configs:
  - <Action 1>
  - <Action 2>
  - <Action 3>

  - job_name: "consul-prometheus"
    consul_sd_configs:
    - server: 'localhost:8500'
      token: "a0de7f26-127b-cd67-f01e-477c212d7c48"
    relabel_configs:
      - source_labels: ['__meta_consul_service']
        regex: .*monitor.*
        action: keep
      - source_labels: ['__meta_consul_service_address']
        target_label: ip
      - source_labels: ['__meta_consul_service_port']
        target_label: port

action常用配置项示例

#   replace: 进行标签替换。
#   lowercase: 转换成小写。
#   uppercase: 转换成大写。
#   keep: 如果标签匹配，则保留整个采集目标。
#   drop: 如果标签匹配，则丢弃整个采集目标。
#   keepequal: 如果内部存在相同标签，则保留整个采集目标。
#   dropequal: 如果内部存在相同标签，则丢弃整个采集目标。
#   hashmod: 将源标签哈希取模的结果，赋值到目标标签。
#   labelmap: 从源标签提取字段到目标标签。
#   labeldrop: 从源标签中删除匹配的标签。
#   labelkeep: 从源标签中保留匹配的标签。
# 默认为 replace，即执行标签替换动作。
action: <relabel_action>

# 参考的源标签集合，注意这里是列表的标签串联形式，来给 action 执行操作时参考的来源指标集合。
# 默认为空。
source_labels:
  - <labelname>
  - <labelname>

# 在 source_labels 中每个串联标签的连接符号，因为 relabel 里的 action 大部分都是针对文本操作的，需要将列表转换为文本组织。
# 默认为 ; 符号，即产生的结果为 <labelname>;<labelname>;<labelname> 。
separator: ';'

# 需要处理的目标指标，比如对比、新增、修改、删除等行为，需要使用此字段。
# 默认为空。
target_label: <labelname>

# action 使用的正则匹配语句，可以针对 source_labels 串行后的文本，进行匹对、过滤、分组等正则操作。
# 默认为 '(.*)'，即匹配所有。
regex: <regex>

# 如果 action 为 hashmod，使用这个参数来设置取模的数值。
# 默认为空。
modulus: 0

# 如果 action 里涉及标签替换的动作，将会使用此字段来构造目标字符串，这里可以使用 regex 里面的正则分组。
# 默认为 $1，如果没分组则是整个匹配字符串，如果分组了，则为第一组。
replacement: '$1'

3.4.3.action常用操作示例

在这里我们以consul服务发现为基础,使用consul的discoverLabels为例，对action的每个操作进行演示

Before Relabeling:
	"__address__": "192.168.56.131:9273",          #当前Target实例的地址<host>:<port>
	"__meta_consul_address": "192.168.56.131",     #consul地址
	"__meta_consul_dc": "prod",	                   #consul数据中心名称
	"__meta_consul_health": "passing",             #target服务状态
	"__meta_consul_node": "consul-node",           #consul名称
	"__meta_consul_service": "monitor_agent",      #target在consul中注册的服务名称
	"__meta_consul_service_address": "192.168.56.131", #consul地址
	"__meta_consul_service_id": "telegraf-192.168.56.131-9273", #target注册到consul中的唯一标识
	"__meta_consul_service_metadata_monitorType": "monitor_agent", #在target注册到consul时 自定义的meta
	"__meta_consul_service_metadata_organization": "运维监控平台", #在target注册到consul时 自定义的meta
	"__meta_consul_service_metadata_project": "监控agent组件", #在target注册到consul时 自定义的meta
	"__meta_consul_service_metadata_version": "v1.22.4", #在target注册到consul时 自定义的meta
	"__meta_consul_service_port": "9273",  #端口
	"__meta_consul_tagged_address_lan_ipv4": "192.168.56.131",
    "__meta_consul_tagged_address_wan": "192.168.56.131",
    "__meta_consul_tagged_address_wan_ipv4": "192.168.56.131",
	"__meta_consul_tags": ",telegraf,",  #与服务关联的标签
	"__metrics_path__": "/metrics",   #指定 Prometheus 用于抓取指标的路径
	"__scheme__": "http",            #指定协议，默认为http
	"__scrape_interval__": "15s", #指定抓取的时间间隔
	"__scrape_timeout__": "10s", #指定抓取的超时时间
	"job": "consul-prometheus" #采集任务名称

3.4.3.1. 标签转换之replace操作

replace 是默认的动作，使用 regexp 的正则对串行源标签值做匹配，并将正则结果提取到目标标签。

replace示例

#因为默认操作就是replace,可以不用写
    relabel_configs:
      - source_labels: [__address__]
        regex: (.*):([0-9]+)
        replacement: '${1}'
        target_label: ip

解释:
	source_labels 选择了需要的提取内容的源标签，然后会用 separator 将其标签值串行拼接起来，因为没有定义 separator，这里是默认的 ; 符号。
	因此，上述正则操作的文本内容应该为  192.168.56.131:9273;
	经过正则匹配后，replacement 规定了 $1的结果，其中 $1 正则匹配结果的第一组，并把这个结果赋值给 ip 这个标签。
	我们借助正则在线工具，查看整个过程，如下图所示

最终，discoveredLabels 经过 relabel 后，产生的新标签 ip 也加入到了采集目标的全局标签内.
通过 targets 接口得到 labels 除了内置的标签外，新增了我们预期的标签，这个就是最基础的 relabel replace操作

3.4.3.2. 标签转换之uppercase操作

uppercase 的操作更加的简单，不需要正则处理，直接将源标签值转变为大写

需求：将 __meta_consul_dc 转变为 env_dc 标签内容，并且要求值必须是大写字母

relabel_configs:
  - action: uppercase
    source_labels: [__meta_consul_dc]
    target_label: env_dc

这个 action 不使用正则，因此可以忽略 regex 和 replacement，操作过程也更加简单
就是把 source_labels 指定的标签都转化为大写字母，赋值给 env_dc 标签，结果如下所示

3.4.3.3. 标签转换之lowercase操作

恰好与uppercase操作相反，同时也不需要正则处理，直接将源标签值转变为小写

需求：将 上个操作将 uppercase 产生的大写字母标签 env_dc的值 再转变为小写字母的值

relabel_configs:
  - action: lowercase
    source_labels: [__meta_consul_dc]
    target_label: env_dc

这个 action 不使用正则，因此可以忽略 regex 和 replacement，操作过程也更加简单
就是把 source_labels 指定的标签的值都转化为小写字母，赋值给 env_dc 标签，结果如下所示

3.4.3.4. 标签转换之hashmod操作

hashmod这个操作暂时还无法理解这个操作能带来什么收益，其实，这个主要是对 Prometheus 分片扩展设计的。
比如有 5 个 Prometheus，那么通过计算标签的哈希除以 5 取模
那么每个 Prometheus 都可以错开且均衡地采集指标，从而达到性能的水平扩展

需求：对 __meta_consul_service_id 标签哈希取模，总数为 5，并赋值到 job 标签。

relabel_configs:
  - action: hashmod
    source_labels: [__meta_consul_service_id]
    target_label: job
    modules: 5

这是对一个已经存在的标签进行了重新赋值，而且是 Prometheus 内部标签 job。
job 标签确实非常关键，但是其仅仅在初始化这个 job_name 下的采集资源时使用，并且保留到采集目标的 labels 内，
但是，由 relabel 重定义或者采集目标自身提供了 job 标签的话，依旧可以将原有的 job 给替换掉
job 在初始化资源之后，就意味着并不再是神圣不可侵犯，我们可以按需对其进行调整.
以下是替换后的结果
{
    "labels": {
        "instance": "192.168.56.131:9273",
        "job": "1"
    }
}

注意：此处仅仅是举例说明，在实际使用中，建议还是保留 job 的原值，不要对这个内置标签做 relabel 操作，因为在排查定位时，可以使用 job 标签与 job_name 的名称，快速定位到 Prometheus 的配置块

3.4.3.5. 标签转换之labelmap操作

它的作用主要是从服务发现到的 discoveredLabels 标签里，根据正则匹配，提取出标签名并将原有的值赋值给对应的标签名。
上面介绍的那些操作，都还是需要指定标签名来处理标签值再将值赋值到 target_label 定义的目标标签里，其实没有对标签名称进行操作
而 labelmap 的亮点，就是能够适应地动态地产生标签名

需求: 将 __meta_consul_service_metadata_ 为前缀的标签，去除前缀后，将键值对作为最终标签

    relabel_configs:
      - action: labelmap
        regex: '__meta_consul_service_metadata_(.+)'
注意: 这里不再依赖 source_labels，因为在 labelmap 里，regex 是对所有以__meta_consul_service_metadata_开头的标签匹配的

3.4.3.6. 标签转换之labeldrop操作

labeldrop 是考虑如何去除标签，它会将 regex 命中匹配的标签，从标签集合中去除，不再传递到 labels 字典里

需求：将 job 标签去除

relabel_configs:
  - action: labeldrop
    regex: '^job$'

补充一个知识点，Prometheus 里面，如果一个标签的值是空字符串，那么也意味着这个标签不存在。
既然这样，我们可以通过 replace 操作将标签重写为空字符串，实现跟 labeldrop 一样的效果
relabel_configs:
  - source_labels: [job]
    target_label: job
    replacement: ''

3.4.3.7. 标签转换之labelkeep操作

labelkeep 是相反的操作，仅保留匹配的标签，其他不匹配的则通通去除

需求：只保留 instance 这个标签

#错误配置示例
relabel_configs:
  - action: labelkeep
    regex: '^instance$'

#错误解读
如果应用了上面的配置，则会得到如下的结果
[root@python2 prometheus]# curl http://192.168.56.131:9090/api/v1/targets -uadmin:QAZXCFRF
{
    "status": "success",
    "data": {
        "activeTargets": [],
        "droppedTargets": [],
        "droppedTargetCounts": {
            "prometheus-core": 0
        }
    }
}
此时会发现没有任何采集目标，也没有任何的标签集合。
原因:
1、 discoveredLabels 里面的标签也是服务发现传递给采集流程的初始化配置
2、采集流程还需要使用里面的 __address__ 来构造采集目标，如果被 relabel 清除了，
	那么就相当于服务发现没有给采集单元传递可以采集的 Targets，也意味着不会产生任何的 activeTargets

#正确配置示例
至少要保留采集需要的核心指标 (内部标签)，修改配置如下
relabel_configs:
  - action: labelkeep
    regex: '^(instance|__.*?__)$'

3.4.3.8. 采集控制之keep操作

keep 是将标签满足匹配的 Targets，保留下来继续采集，其他的则丢弃 (drop)，不再采集，也不会再传入到下一步的 relabel 中。

刚提到的 标签转换labelkeep操作，将标签全部清除后，导致采集丢失的现象，也大概能知道 keep 执行了那些类似的动作。

但是 Prometheus 并不会主动把这些标签给清除 (remove)，而是作为被丢弃采集的对象，放到 droppedTargets 里记录。

需求: 只保留__meta_consul_service 为 monitor_agent采集目标

 relabel_configs:
   - source_labels: ['__meta_consul_service']
     regex: .*monitor_agent.*
     action: keep

3.4.3.9. 采集控制之drop操作

drop 是将标签满足匹配的 Targets，进行丢弃 (drop)，其他的继续采集，并会传入到 relabel 的下一步进行处理

需求：丢弃 __meta_consul_service_id 为telegraf-192.168.56.131-9273的采集目标

relabel_configs:
  - action: drop
    source_labels: [__meta_consul_dc]
    regex: '^telegraf-192.168.56.131.*$'

因为我的consul服务发现目前只注册了telegraf-192.168.56.131-9273这一个采集目标，因此发现的目标都能够正常采集

3.4.3.10. 采集控制之keepequal操作

keepequal 使用标签相等匹配，来判断 source_labels 里每个标签是否与 target_label 的相等，如果相等，则保留采集目标

需求：保留__meta_consul_service和job_name一致的采集目标，不一致的被丢弃

relabel_configs:
  - action: keepequal
    source_labels: [__meta_consul_tagged_address_lan]
    target_label: job

3.4.3.11. 采集控制之dropequal操作

dropequal使用标签相等匹配，来判断source_labels里每个标签是否与target_label 的相等，如果相等，则丢弃(drop)采集目标

需求：只采集与 job_name 同名的服务

relabel_configs:
  - action: dropequal
    source_labels: [__meta_consul_service]
    target_label: job

我的注册服务是 monitor_agent，而 Prometheus 配置的 job_name 是 consul-prometheus，
那么会发现采集目标会被添加到 activeTargets 开始采集。
如果两者一致则会被添加到dropTargets中，不进行采集

4.构造标签

目的:
	一些指标的标签并不是我们直接需要的，某些时候我们需要提取、组装或清洗部分标签，来达到提升标签查询准确率、
	提高 PromQL 查询关联性和减少存储空间占用等作用，
	这些都依赖于 relabel 的链式执行效果，让监控标签可以灵活运用

四、监控规则

1.规则分类

Prometheus支持两种类型的规则:
	记录规则和警报规则。 
要在Prometheus中包含规则，请创建一个包含必要规则语句的文件，并让Prometheus通过Prometheus配置中的rule_files字段加载规则文件。如下所示

2.警报规则

警报规则 rules 使用的是 yaml 格式进行定义，Prometheus 会根据设置的警告规则 Ruels 以及配置间隔时间进行周期性计算，当满足触发条件规则会发送警报通知。 
警报规则加载的是在 prometheus.yml 文件中进行配置，默认的警报规则进行周期运行计算的时间是1分钟，可以使用 global 中的 evaluation_interval 来决定时间间隔

3.警报规则示例

在告警规则模版中，可以将相关的规则设置在一个groups下面，一个groups可以定义多个告警规则。alert：告警规则的名称。

groups:
- name: operations
  rules:
  - alert: node-down
    expr: up{env="operations"} != 1
    for: 5m
    labels:
      status: High
      team: operations
    annotations:
      description: "Environment: {{ $labels.env }} Instance: {{ $labels.instance }} is Down ! ! !"
      value: '{{ $value }}'
      summary:  "The host node was down 20 minutes ago"

参数解读:
	expr: 基于PromQL表达式告警触发条件，用于计算是否有时间序列满足该条件。
	for: 评估等待时间，可选参数。用于表示只有当触发条件持续一段时间后才发送告警。在等待期间新产生告警的状态为pending。
	labels: 自定义标签，允许用户指定要附加到告警上的一组附加标签。
	annotations: 用于指定一组附加信息，比如用于描述告警详细信息的文字等，annotations的内容在告警产生时会一同作为参数发送到Alertmanager。

4.报警状态

告警分成 3 个状态，Inactive、Pending、Firing
Inactive: 非活动状态，表示正在监控，但是还未有任何警报触发 ，正是HostDown规则的状态。
Pending: 表示这个警报必须被触发。由于警报可以被分组、压抑/抑制或静默/静音，所以等待验证，一旦所有的验证都通过，则将转到 Firing, 比如MemUtil 规则 设置for 1m，表示触发规则连续一分钟才会告警，我们在prometheus.yml 设置了evaluation_interval的执行频率为15s 得连续4次都触发阈值才告警。
Firing: 将警报发送到 AlertManager，它将按照配置将警报的发送给所有接收者。一旦警报解除，则将状态转到 Inactive，如此循环。

5.警报规则编写

5.1.从指定网址获取规则并进行修改

https://samber.github.io/awesome-prometheus-alerts/rules

虽然上述规则是node_exporter组件对应的规则文件，我们使用的是telegraf，其实相差不大，我们可以参考该配置文件进行修改即可使用

5.2.自定义编写告警规则文件

该方法会在prometheus+telegraf自定义监控指标文章中进行描述

总结

标签重写 (relabel) 是 Prometheus 技术栈里非常关键的一环，对整个监控周期里的服务发现、采集请求、数据写入、规则计算、告警通知和分布式监控等阶段都产生巨大的影响，如果能够掌握这门技巧，并且灵活应用到各个方面，相信 Prometheus 架构也能够为自身带来非常多的功能回馈。如果这一篇章的内容你还无法全部吃透，非常建议你收藏此文，在需要的时候翻阅，重新认识一遍这方面的内容，甚至在需要的时候，可以直接将案例中的配置进行修改，就可以应用到你的生产环境。