Prometheus 标签label的作用

标签的作用

---

标签作用： Prometheus中存储的数据为时间序列，是由Metric的名字和一系列的标签(键值对)唯一标识的，不同的标签代表不同的时间序列，即通过指定标签查询指定数据 。

不同的标签代表不同的时间序列，即通过指定标签查询指定数据。指标+标签实现了查询条件的作用，可以指定不同的标签过滤不同的数据。

 

Relabeling 重新标记

---

Relabeling 重新标记用于配置 Prometheus 元信息的方式，它是转换和过滤 Prometheus 中 label 标签对象的核心。

Prometheus在抓取目标配置完成之后，就会将监控的目标抓取过来。抓取过来之后，下面会有很多label标签，有些label标签需要我们去过滤，做一些转换，可能某些序列不是我们想要的，这个时候就需要将这个序列过滤掉，有些时候可能需要添加标签或者将里面的标签更改掉，这个时候就需要Relabeling，这些配置还是在Prometheus配置文件里面配置。

概述

---

Prometheus 发现、抓取和处理不同类型的 label 标签对象，根据标签值操作或过滤这些对象非常有用，比如：

• 只监视具有特定服务发现注解的某些目标，通常在服务发现中使用（主要在服务发现当中，因为服务发现会自动将抓取的目标添加元信息，根据这些元信息做一些过滤）
• 向目标抓取请求添加 HTTP 查询参数（查询的路径不是metrics需要做些替换）
• 仅存储从指定目标中提取样本的子集（有些样本不需要，需要将其过滤掉）
• 将抓取序列的两个标签值合并为一个标签

主要就是重写标签值，添加标签，从一个标签映射到另外一个标签 

Relabeling 是作为一系列转换步骤实现的，我们可以在 Prometheus 的配置文件中应用这些步骤来过滤或修改标记对象，我们可以对一下类型的标记对象应用 Relabeling 操作：

• 发现的抓取目标（relabel_configs）
• 抓取的单个样本（metric_relabel_configs）
• 发送给 Alertmanager 的报警（alert_relabel_configs）
• 写到远程存储的样本（write_relabel_configs）

平时在配置监控目标的时候我们更多的会用 relabel_configs 与 metric_relabel_configs 两个配置

1. 采集数据之前，通过 relabel_configs
2. 采集数据之后，写入存储之前，通过 metric_relabel_configs 进行配置。

所有这些 relabeling 配置块都是相同类型的 relabel_config，每个配置块都由一个规则列表组成，这些规则依次应用与每个标记的对象。(重新标记的时候有一系列的规则，应用了规则1之后转换为另外一个对象，然后规则2又去应用它，然后规则3又去应用它，最后将处理后的对象输出出来)

例如，一个 relabeling 规则可以根据正则表达式的匹配来保留或丢弃一个对象，可以修改其标签，也可以将一整组标签映射到另一组。一旦一个 relabeling 步骤决定放弃一个有标签的对象，就不会对这个对象执行进一步的 relabeling 步骤，它将从输出列表中删除。

Metadata标签

---

在被监控端纳入普罗米修斯里面定义了一些元数据标签，在Prometheus所有的Target实例中，都包含一些默认的Metadata标签信息。可以通过Prometheus UI的Targets页面中查看这些实例的Metadata标签的内容：

• __address__：当前Target实例的访问地址<host>:<port>

• __scheme__：采集目标服务访问地址的HTTP Scheme，HTTP或者HTTPS

• __metrics_path__：采集目标服务访问地址的访问路径

上面这些标签将会告诉Prometheus如何从该Target实例中获取监控数据。除了这些默认的标签以外，我们还可以为Target添加自定义的标签。

在抓取被监控端就会带上这些标签，这些标签就是声明要采集谁，协议是什么，以及暴露的接口是谁。

一般来说元标签只是普罗米修斯去使用，我们一般不会让其做什么事情，并且这些标签是不会写到数据库当中的，使用promql是查询不到这些标签的，因为这些标签只是普罗米修斯内部去使用的，不会存储在时序数据库供我们查询。

自定义标签

---

可以自定义标签，有了这些标签可以针对特定的标签去查询，比如根据机房，或者项目查询某些机器，添加的标签越多，查询的维度越细。

  - job_name: 'BJ Linux Server'
    basic_auth:
      username: prometheus
      password: 123456
    static_configs:
    - targets: ['192.168.179.99:9100']
      labels:
        idc: tongniu
        project: www

  - job_name: 'Shanghai Linux Server'
    basic_auth:
      username: prometheus
      password: 123456
    static_configs:
    - targets: ['192.168.179.99:9100']
      labels:
        idc: sss
        project: blog

可以看到基于自定义标签实现多维度的查询

隐藏的标签与元数据

---

以双下划线__开头的标签属于特殊的标签，它们在重新标记后会被删除。

标记对象的来源最初可以附加这些隐藏的标签，以提供关于标记对象的额外元数据，这些特殊的标签可以在 relabeling 阶段被用来对对象的标签进行修改。

这些都是普通的标签，没有下划线开头的。 

下面这些以双下划线开头和双下划线结尾的这些标签名称，这些都是特殊的标签，可以对这些标签做relabel操作，操作完之后这些标签就删除了。

Discovered Labels可以映射为我们的目标标签Target Labels，只保留job instance标签，这里address就映射为instance这个标签了，其余的元标签以_xx_格式的就不要了，最后就只保留了job和instance标签。

    - job_name: 'kubernetes-node-exporter'
      kubernetes_sd_configs:
      - role: node
      relabel_configs:
      - source_labels: [__address__]
        regex: '(.*):10250'
        replacement: '${1}:9100'
        target_label: __address__
        action: replace

      - action: labelmap
        regex: __meta_kubernetes_node_label_(.+)

对于抓取指标，其中就包含一些隐藏的标签，可以用来控制目标应该如何被抓取。

• __address__：包含应该被抓取目标的地址，最初默认为服务发现机制提供的 <host>:<port>，如果在此之前没有明确地将实例标签 instance 设置为其他值，那么在 relabeling 之后，Prometheus 会将 instance 标签设置为 __address__ 的值。（如果替换了，会根据替换之后的地址去抓取）
• __scheme__：抓取目标的请求模式，包括 http 与 https，默认为 http。
• __metrics_path__：表示用于采集指标的 HTTP 路径，默认为 /metrics。（如果提供了metrics路径不在__metrics_path__下面，那么可以对其使用relabel操作的，将里面的值做一个替换）
• __param_<name>: 包含 HTTP 查询参数名称和它们的值。

上面的这些标签都可以使用 relabeling 规则来设置或覆盖，这样就可以为抓取目标进行自定义抓取行为。

此外，服务发现机制也可以提供一组以 __meta_ 开头的标签，包含关于目标的特定发现元数据。例如，当发现 Kubernetes 集群中的 pod 时，Kubernetes 服务发现引擎将为每个 pod 目标提供一个 __meta_kubernetes_pod_name 的标签，包含被发现的 pod 的名字，以及一个 __meta_kubernetes_pod_ready 标签，表明 pod 是否处于就绪状态，关于服务发现生成的元标签可以查看官方文档 Configuration | Prometheus 了解更多。

如果一个 relabeling 步骤需要将一个值保存到一个临时标签中（以便在随后的步骤中处理），那么我们可以使用 __tmp 标签名称前缀进行标记，以 __tmp 开通的标签是不会被 Prometheus 本身使用的。