Prometheus标签

本章重点： 标签说明，标签二次处理，标签打标规则，重新打标说明

参考：prometheus监控实战一书+ai优化

一、标签核心认知

标签是Prometheus时间序列数据的核心维度，其核心作用是为指标提供上下文信息、定义监控目标，与指标名称共同构成时间序列的唯一标识——标签的任何变更（新增、修改、删除）都会生成全新的时间序列。

⚠️关键警示：标签变更会断裂历史数据连续性，导致监控图表断层、警报规则失效等问题，需谨慎设计标签体系并尽量保持稳定。

二、Target重新打标：抓取前的标签预处理

Target重新打标是在指标抓取前对监控目标标签的预处理操作，支持删除标签、修改标签值、重命名标签等场景。每个抓取配置（scrape_configs）中可定义多组打标规则，按顺序执行。

2.1 默认打标行为

Prometheus对发现的每个Target会自动执行以下默认打标操作，无需手动配置：

1. 将job标签值设为当前抓取配置的job_name；

2. 将__address__标签值设为Target的“IP:端口”套接字地址；

3. 将instance标签值默认设为__address__的值；

4. 将__scheme__标签值设为抓取协议（默认http）；

5. 将__metrics_path__标签值设为指标抓取路径（默认/metrics）；

6. 将__param_<name>标签值设为URL参数中第一个名为的值。

   以第三章获取的node为例

   instance="node1.example.com:9100"
   job="node-exporter-node1"
   Discovered labels:
   __address__="node1.example.com:9100"
   __meta_dns_name="_node1._tcp.example.com"
   __meta_dns_srv_record_port="9100"
   __meta_dns_srv_record_target="node1.example.com."
   __metrics_path__="/metrics"
   __scheme__="http"
   __scrape_interval__="1m"
   __scrape_timeout__="10s"
   job="node-exporter-node1"
   

2.2 核心打标规则配置

通过relabel_configs定义打标规则，核心配置字段如下（方括号表示可选）：

# 1. 源标签：从现有标签中选择值，多标签会按separator拼接
[ source_labels: [ <labelname> [, ...] ] ]
# 2. 分隔符：多源标签值的拼接符，默认分号(;)
[ separator: <string> | default = ; ]
# 3. 目标标签：替换或新增的标签名（replace动作必选）
[ target_label: <labelname> ]
# 4. 正则表达式：匹配源标签值的模式，默认匹配所有(.*)
[ regex: <regex> | default = (.*) ]
# 5. 哈希模：对源标签哈希值取模（仅hashmod动作使用）
[ modulus: <int> ]
# 6. 替换值：匹配后替换的内容，支持引用正则分组（$1表示第一个分组）
[ replacement: <string> | default = $1 ]
# 7. 执行动作：核心操作类型，默认replace
[ action: <relabel_action> | default = replace ]

2.3 七大核心动作详解

这里定义上面第7步action动作

动作类型	作用说明	关键场景
replace	拼接源标签值并匹配正则，将结果赋值给目标标签	修改标签值、拼接多标签生成新标签
hashmod	对源标签哈希值取模，结果赋值给目标标签	负载均衡、数据分片
keep	正则不匹配源标签值时，删除该Target	保留特定标签的目标（如生产环境节点）
drop	正则匹配源标签值时，删除该Target	剔除无效目标（如测试环境节点）
labelmap	用正则匹配所有标签名，按替换规则生成新标签	批量重命名标签（如给标签加前缀）
labeldrop	用正则匹配标签名，删除匹配到的标签	剔除冗余标签（如敏感元数据）
labelkeep	用正则匹配标签名，保留匹配到的标签，删除其他	精简标签集（如仅保留核心业务标签）

2.4 打标关键注意事项

• 元标签使用：打标时可引用服务发现生成的__meta_*元标签（如K8s的__meta_kubernetes_pod_name）；
• 临时标签前缀：如需临时存储标签值，需用__tmp为前缀（如__tmp_temp_label），避免与内置标签冲突；
• 内置标签清理：打标完成后，所有以__开头的标签会自动删除，无需手动处理。

三、标签分类：标准化标签体系设计

合理的标签分类可提升监控数据的可分析性，推荐按“拓扑维度”和“业务模式维度”划分：

分类	定义	典型标签示例	核心作用
拓扑标签（Topological Label）	按物理或逻辑架构划分服务组件的标签	job（任务名）、instance（实例名）、namespace（命名空间）、node（节点名）	定位监控目标的部署位置和所属任务
模式标签（Schematic Label）	描述业务特征或请求属性的标签	service（服务名）、env（环境）、error_code（错误码）、user（用户）、method（请求方法）	实现业务维度的聚合分析（如按环境统计错误率）

最佳实践：固定拓扑标签（如job、instance），按需扩展模式标签（如env、service），避免标签数量过多（单指标建议不超过10个标签）。

四、标签实操：常用场景配置示例

以下示例基于文件服务发现（file_sd）或静态配置，核心规则可复用至其他服务发现模式（如K8s SD）。

4.1 标签添加：静态添加与批量生成

场景1：静态配置直接添加标签

适用于静态目标，直接在配置中定义业务标签：

[root@localhost targes]#  cat /data/prometheus/prometheus.yml 
  - job_name: 'file-node'
    file_sd_configs:
      - files:
          - "/data/prometheus/targes/node.yml"
        refresh_interval: 10s


[root@localhost targes]#  cat /data/prometheus/targes/node.yml
- targets: ["10.4.50.130:9100"]
  labels:
    env: "production"
    job: "node1"

# 查看 prometheus9090 status--> target health

场景2：批量重命名标签（labelmap）

将现有标签名按规则重命名并生成新标签，原标签可通过labeldrop删除：

# 错误的替换，promethes自动设置的值，在替换时使用labelmap会产生空值现象，可以用replace进行替换
  relabel_configs:
    - regex: "^(job|app).*        <-- job 标签默认由 Prometheus 自动设置为 job_name，若想修改它，需用 replace 动作显式处理，而非 labelmap
      replacement: "${1}_name" 
      action: labelmap

#### 示例
  - job_name: 'file-node'
    static_configs:
      - targets: ["10.4.50.130:9100"]
        labels:
          env: "production"
    relabel_configs:
      - source_labels: [job]
        target_label: job_name
        action: replace  # 用 replace 替代 labelmap，避免空键

# web界面展示值，可以发现由于job是系统生成的，它还是会生成。
env="production"，instance="10.4.50.130:9100"，job="file-node"，job_name="file-node"

# 当我们在使用action: drop删除原始标准时，No active targets in this scrape pool，job 标签是 Prometheus 最重要的元标签之一，用于标识指标来自哪个任务。删除它会使你难以在 Grafana 等工具中按任务筛选和聚合数据
    relabel_configs:
      - source_labels: [job]
        target_label: job_name
        action: replace  # 用 replace 替代 labelmap，避免空键
      - source_labels: [job]
        action: drop  # 删除原始 job 标签

# 不建议删除元数据  如果硬要用可以用 metric_relabel_configs

• 异常分析一下

  1. Prometheus 发现了目标 10.4.50.130:9100。
  2. 它为这个目标添加了元数据标签，其中就包括 job="file-node"。
  3. relabel_configs 开始执行：
     • 第一条规则：复制 job 标签的值到 job_name 标签。现在目标的元数据标签有 job="file-node" 和 job_name="file-node"。
     • 第二条规则：检查是否存在 job 标签（这总是 true）。因为规则匹配，所以执行 action: drop。
  4. 结果：整个目标被丢弃，不进行任何抓取。因此，在 UI 上显示 “No active targets”。

• 普通标签的删除

    - job_name: 'file-node'
      static_configs:
        - targets: ["10.4.50.130:9100"]
          labels:
            env: "production"
            test_flag: "node1"
      relabel_configs:
        - source_labels: [test_flag]
          target_label: "flag_test"
          action: replace
        - regex: "^test_flag"
          action: labeldrop
  # 将test_flag 改成 flag_test, 如果不删除，那么两者都会存在
  

4.2 标签替换：多标签拼接与格式优化

将协议、地址、路径等标签拼接为标准端点地址，赋值给新标签endpoint：

- job_name: 'file-node2'  # 定义当前抓取任务的名称，将作为目标的默认job标签值
  static_configs:  		  # 静态目标配置（适用于固定地址的目标，无需服务发现）
  						  # 要抓取的目标地址（IP:端口，这里是node-exporter的默认端口9100）
    - targets: ["10.4.50.139:9100"]  
      labels:  		      # 为该目标添加自定义标签（抓取后会附加到所有指标上）
        env: "file2"      # 环境标签，标识该目标属于"file2"环境
  
  relabel_configs:		  # 标签重写规则：在抓取目标前对目标的元数据标签进行处理
    # 规则1：将协议、地址、指标路径拼接为完整的访问URL，存入endpoint标签
    - source_labels: [__scheme__, __address__, __metrics_path__]  # 要读取的元数据标签
      # __scheme__：抓取协议（默认http，可通过scheme字段修改）
      # __address__：目标地址（即targets中配置的IP:端口）
      # __metrics_path__：指标路径（默认/metrics，可通过metrics_path字段修改）

      separator: ""  # 多个source_labels值的拼接分隔符，设为空表示直接拼接（无分隔符）
      regex: "(http|https)(.*)(/.*)"  # 正则表达式，用于分组匹配source_labels的拼接结果
      # 分组说明：
      # (http|https)：第1组，匹配协议（http或https）
      # (.*)：第2组，匹配地址（IP:端口，如10.4.50.139:9100）
      # (/.*)：第3组，匹配指标路径（如/metrics）

      target_label: "endpoint"  # 重写后的目标标签名，即最终生成的标签叫"endpoint"
      replacement: "${1}://${2}${3}"  # 标签值的替换规则，用正则分组拼接成完整URL
      # 替换说明：
      # ${1}：引用正则第1组（协议）
      # ${2}：引用正则第2组（地址）
      # ${3}：引用正则第3组（指标路径）
      # 最终结果示例：http://10.4.50.139:9100/metrics

      action: replace  # 动作类型：替换（将处理后的结果写入target_label指定的标签）

五、Metrics重新打标：抓取后的指标处理

Metrics重新打标（metric_relabel_configs）与Target打标逻辑完全一致，区别在于执行时机——在指标抓取后、存储前执行，用于处理指标级别的标签或过滤指标。

5.1 核心使用场景

1. 删除无用指标（如Go语言内置指标）；
2. 修改指标的标签值或新增标签；
3. 剔除指标中的敏感标签（如包含IP的instance标签）。

5.2 常用配置示例

  - job_name: 'file-node2'
    static_configs:
      - targets: ["10.4.50.139:9100"]
        labels:
          env: "file2"  # 修复缩进：与labels同级缩进一致
  
    # 指标标签重写（抓取指标后执行）
    metric_relabel_configs:
      # 规则1：删除特定指标（go_gc_duration_seconds 和 go_info）
      - source_labels: [__name__]  # 匹配指标名
        regex: '^go_gc_duration_seconds$|^go_info$'  # 仅匹配完整的指标名，避免部分匹配
        action: drop  # 修复缩进：与其他字段同级
  
      # 规则2：用instance标签的值生成cce标签（必须在删除instance前执行）
      - source_labels: [instance]  # 读取instance标签（如10.4.50.139:9100）
        regex: '(.*)'  # 匹配整个instance值
        replacement: "$1"  # 直接复用instance的值作为cce的值
        target_label: cce  # 生成新标签cce
        action: replace  # 修复缩进：与其他字段同级
  
      # 规则3：删除原始的instance标签（在生成cce后执行）
      - regex: 'instance'  # 匹配标签名instance
        action: labeldrop  # 修复缩进：与其他字段同级

# go_gc_duration_seconds 跟 go_info 也是直接用QL语句查询

# 如果界面一直没有cce 跟 instance一直存在， 我们就用promQL语句查询一下
node_cpu_seconds_total{job="file-node2"}
# 查询结果: node_cpu_seconds_total{cce="10.4.50.139:9100", cpu="0", env="file2", job="file-node2", mode="idle"}	

六、标签使用最佳实践

1. 标签命名规范：使用小写字母+下划线（snake_case），避免特殊字符，标签名需语义清晰（如用env而非e）；
2. 避免高频变更：拓扑标签（job、instance）建议永久固定，模式标签（如user）避免用于高频变化的维度（可改用日志记录）；
3. 控制标签数量：单指标标签不超过10个，避免“标签爆炸”导致存储和查询性能下降；
4. 复用元标签：服务发现生成的__meta_*标签可直接用于打标（如K8s的命名空间、Pod名）；
5. 测试打标效果：通过Prometheus WebUI的“Status → Targets”查看打标后的标签，确认规则生效后再上线。