配置文件

配置文件结构

参考文档：https://prometheus.io/docs/prometheus/latest/configuration/configuration/

# 全局配置段，包括抓取间隔和评估间隔等。
global:
...

# 指定需要被抓取的目标，支持服务发现、静态配置等方式。
scrape_configs:
...


# 告警规则定义
rule_files:
...

# 定义报警发往何处
# 定义用于触发警报的规则。这些规则基于时间序列数据的评估，当满足特定条件时，将会触发相应的警报。
alerting:
...

# 允许将时间序列数据远程写入其他存储后端，如 Cortex、Thanos 等。
remote_write:
...

# 配置 Prometheus 实例以从其他存储后端读取时间序列数据。
remote_read:
...

# 指定 Prometheus 的本地存储选项，例如数据的保存路径、保留策略等。
storage:
...

global

global:
  scrape_interval: 1m # 多久 Pull 一次 Targets 上的指标数据（向 /metrics 发送 GET）
  scrape_timeout: 10s # Pull Targets 的超时时间，超时则无法获得本次指标数据（Target 显示 DOWN）
  evaluation_interval: 1m # 告警规则和记录规则的评估间隔时间。
  external_labels: # 所有由该 Prometheus 实例抓取和记录的时间序列都会自动带上这些标签。
    # 这些标签来区分来自不同 Prometheus 实例的指标数据；
    # 使用 Thanos 或 Cortex 等系统将多个 Prometheus 实例的数据聚合到一个中心存储时，这些标签能确保所有数据点的来源是唯一且可识别的。
    prometheus: kubesphere-monitoring-system/k8s
    prometheus_replica: prometheus-k8s-1

什么是告警规则和记录规则？

  • 告警规则定义了在什么条件下，Prometheus 应该生成一个警报。记录规则定义了一个新的、预先计算好的时间序列指标。

scrape_configs

  • scrape_configs 用于定义要由 Prometheus 抓取（scrape）的目标。每个scrape_configs块中包含一个或多个job，而job定义了要抓取的一组目标以及与该组目标相关的配置。
  • 方式分为静态配置和服务发现两种，服务发现可基于文件、k8s、consul 等。

kubernetes_sd_configs

scrape_configs:
- job_name: serviceMonitor/kubesphere-monitoring-system/kube-apiserver/0 # 相识指标的集合，会在 Prometheus UI 中的 Targets 显示。

  # 1. 抓取行为基本配置
  honor_timestamps: true # 是否保留目标导出的时间戳（通常为 true）。
  scrape_interval: 1m # 抓取该目标指标的时间间隔，优先级高于 global 中的定义。
  scrape_timeout: 10s # 等待目标响应的最大时间，优先级高于 global 中的定义。

  # 2. 连接/安全配置
  metrics_path: /metrics # 抓取指标的 HTTP 路径。
  scheme: https # 连接协议
  follow_redirects: true # 是否跟随 HTTP 重定向。
  authorization: # 授权配置
    type: Bearer # 使用 Bearer Token 进行认证
    credentials_file: /var/run/secrets/kubernetes.io/serviceaccount/token # Token 文件的路径。
  tls_config: # 用于 HTTPS 连接的安全配置
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt # 验证服务端证书的 CA 证书文件路径。
    server_name: kubernetes # 用于 TLS 握手时的 Server Name Indication (SNI)。
    insecure_skip_verify: false # 是否跳过证书验证（false 表示不跳过，需要验证）。

  # 3. 基于 K8s 的服务发现配置
  kubernetes_sd_configs:
  - role: endpoints # 发现 Kubernetes Service 的 Endpoints（即 Pod IP 和端口）。
    kubeconfig_file: "" # KubeConfig 文件，空字符串表示使用 Pod 内部的 ServiceAccount 访问 API。
    follow_redirects: true # 服务发现请求是否跟随重定向。
    namespaces: # namespaces 过滤（限制服务发现的命名空间）
      own_namespace: false # false 表示抓取 names 中定义的 namespaces，true 表示仅抓取当前 Prometheus 运行的 namespaces。
      names:
      - default # 只发现 default 命名空间内的目标。
    # 以上配置表示，Prometheus 只会尝试抓取 default 命名空间内，匹配 role: endpoints 和后续 relabel_configs 条件的目标。

  # 4. Targets Relabel 配置，作用于服务发现 (Service Discovery) 之后，实际抓取 (Scrape) 之前。
  # 用于修改目标的地址、端口，或为目标添加/删除/修改标签（例如 instance, job 等），以决定 是否抓取 该目标。
  # 详情参阅 Prometheus Relabel 文章
  relabel_configs:
  ...

  # 5. Metric Relabel 配置，作用于实际抓取 (Scrape) 之后，存储 (Storage) 之前。
  # 用于修改抓取到的指标的名称或标签（例如 code, method 等），以决定 是否保留 该指标。
  # 详情参阅 Prometheus Relabel 文章
  metric_relabel_configs:
  ...

file_sd_configs

  • 基于文件的服务发现配置，它仅仅略优于静态配置的服务发现方式，它不依赖于任何平台或第三方服务，因而也是最为简单和通用的实现方式
  • Prometheus server 会定期从文件中加载 target 信息
# 在 Prometheus 的配置文件中，需要添加一个 `file_sd_configs` 部分，用于指定服务发现文件的路径。以下是一个简化的例子：
scrape_configs:
  - job_name: 'file-service-discovery'
    file_sd_configs:
      - files:
        - '/path/to/service-discovery-file.json'
# 这个配置告诉 Prometheus 定期读取指定路径下的服务发现文件，并监控其中定义的服务实例。

# =============================================================================================

# 服务发现文件的具体格式取决于你的需求，但通常每个实例都有一些基本信息，例如 IP 地址、端口和标签等。以下是一个简化的 JSON 示例：
# /path/to/service-discovery-file.json
[
  {
    "targets": ["10.0.0.1:8080"],
    "labels": {
      "job": "example-job",
      "env": "production"
    }
  },
  {
    "targets": ["10.0.0.2:8080"],
    "labels": {
      "job": "example-job",
      "env": "staging"
    }
  }
]
# 在这个例子中，有两个服务实例，每个实例都有一个 targets 数组表示实例的地址和端口，以及一个 labels 对象表示实例的标签。

static_configs

  • static_configs 用于定义静态的监控目标和相关的配置。以下是一个使用static_configs的简单示例：
scrape_configs:
  - job_name: 'example_job'
    static_configs:
      - targets: ['localhost:9090', 'example.com:8080']
        labels:
          environment: 'production'
      - targets: ['anotherhost:9100']
        labels:
          environment: 'testing'

在这个例子中，我们定义了一个名为example_job的作业，其中包含两个静态监控目标。第一个目标是localhost:9090，并且被标记为environment: 'production'，而第二个目标是example.com:8080，同样被标记为environment: 'production'。另外，还添加了一个带有environment: 'testing'标签的目标anotherhost:9100。这样，Prometheus就可以使用这些配置来抓取和处理这些目标的监控数据。

配置文件语法检查

promtool check config /monitor/prometheus-2.37.1.linux-amd64/prometheus.yml

scrape_configs

job_name：

job_name 用于标识和区分不同的任务或作业。每个作业都有一个唯一的job_name。在Prometheus中，作业通常是一组具有相似功能的集合。

以下是一个简单的示例，展示了scrape_configs中job_name的用法：

scrape_configs:
  - job_name: 'example_job' # 相似功能的集合
    metrics_path: /metrics # 默认使用HTTP协议在此路径下采集数据
    static_configs:
      - targets: ['localhost:9090', 'example.com:8080']
        labels:
          environment: 'production'

在这个例子中，我们定义了一个名为example_job的作业，指定了两个监控目标（localhost:9090和example.com:8080），并为它们添加了一个标签environment: 'production'。这使得Prometheus能够识别和区分这些目标，并为其应用相应的配置。

job_name在Prometheus配置文件中定义的作业名称会对应到Prometheus的Web界面中的"Targets"部分。

kubernetes_sd_configs

https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config

在Prometheus中，kubernetes_sd_configs是一种服务发现配置，它允许Prometheus从Kubernetes API中自动发现和监控容器化应用程序。当配置为kubernetes_sd_configs时，Prometheus将会查询Kubernetes API服务器以获取有关特定资源（如Pod、Service、Endpoints等）的信息，并基于这些信息生成目标配置。

定义 kubernetes_sd_configs 时，Prometheus具体是怎样与k8s交互的？

当Prometheus配置了kubernetes_sd_configs时，它会与Kubernetes API服务器进行交互，以获取有关Kubernetes中特定资源的信息。这些资源可以是Pod、Service、Endpoints等。Prometheus通过Kubernetes提供的API接口，与Kubernetes集群通信，并获取所需的信息。

具体来说，Prometheus与Kubernetes交互的步骤如下：

  1. 建立连接：Prometheus会使用Kubernetes API的地址和凭据（例如，ServiceAccount Token）来建立与Kubernetes API服务器的连接。这通常是通过API服务器的URL和访问凭据进行身份验证。

  2. 发起请求：一旦连接建立，Prometheus会向Kubernetes API服务器发送请求，请求特定类型（如Pod、Service等）的资源信息。这些请求可能包括筛选器，以指定所需资源的特定条件或标签。

  3. 获取响应：Kubernetes API服务器接收到请求后，会根据请求的内容从集群中检索相应的资源信息，并将其作为响应返回给Prometheus。

  4. 解析响应：Prometheus会解析收到的响应，从中提取出所需的资源信息，例如Pod的IP地址、标签、注解等。

  5. 生成目标配置：根据从Kubernetes API获取到的资源信息，Prometheus会生成目标配置，用于指定监控目标的地址、标签、端口等信息。

  6. 持续更新：一旦生成了目标配置，Prometheus会持续与Kubernetes API保持连接，并定期地更新目标配置。这样，如果在Kubernetes中有新的资源被创建或者现有的资源发生变化，Prometheus都能及时地获取这些变化，并更新其监控目标。

通过与Kubernetes API服务器的交互，Prometheus能够自动地发现和监控Kubernetes集群中的各种资源，实现了自动化的监控配置管理。

但是访问 Kubernetes API 不是需要证书吗，Prometheus 是怎样获取到的？

确实，在与Kubernetes API进行交互时，需要进行身份验证。Prometheus可以通过几种方式获取到与Kubernetes API通信所需的凭据：

  1. Service Account Token（最常用）：Prometheus可以使用Kubernetes集群中的Service Account Token来进行身份验证。在Kubernetes中，每个Pod都被分配了一个Service Account，而且可以配置为自动向Pod注入一个包含访问API服务器所需凭据的Service Account Token。Prometheus可以利用这个Token来向API服务器进行身份验证。

  2. kubeconfig 文件：类似于kubectl工具，Prometheus也可以使用kubeconfig文件来进行身份验证。kubeconfig文件通常包含了连接到Kubernetes集群所需的所有信息，包括服务器地址、证书和凭据等。Prometheus可以配置使用kubeconfig文件中的凭据来访问Kubernetes API。

  3. 证书和私钥：有时，Prometheus也可以直接使用TLS证书和私钥来进行身份验证。这种情况下，管理员可能会将证书和私钥嵌入到Prometheus配置中，以便Prometheus可以使用它们来建立与Kubernetes API服务器的安全连接。

不管使用哪种方式，关键在于Prometheus需要能够获取到正确的凭据，以便与Kubernetes API进行安全的通信。通常情况下，这些凭据会由Kubernetes集群管理员提供，并根据需要配置到Prometheus的相关部署中。

Service Account Token 最常用对吗？

是的，Service Account Token 是在 Kubernetes 中与 Prometheus 进行安全通信最常用的方式之一。这是因为 Kubernetes 默认情况下为每个 Pod 分配了一个 Service Account，而 Service Account Token 就是用来证明 Pod 身份的凭据之一。这种方式具有以下优点：

  1. 自动化配置：Kubernetes 自动将 Service Account Token 注入到 Pod 中，因此 Prometheus 不需要额外的配置步骤来获取凭据。

  2. 安全性：Service Account Token 可以通过 Kubernetes RBAC（基于角色的访问控制）进行权限管理，确保只有经过授权的实体才能访问 Kubernetes API。

  3. 自我更新：Service Account Token 有一个默认的过期时间（通常是 1 小时），一旦过期，Kubernetes 会自动为 Pod 更新 Token，而不需要 Prometheus 进行手动干预。

  4. 集成性：使用 Service Account Token 可以充分利用 Kubernetes 的内置安全机制，使 Prometheus 与 Kubernetes 之间的通信更加密切，有助于实现更好的集成和自动化。

综上所述，Service Account Token 是与 Kubernetes API 进行安全通信时最常用的方式之一，也是一种简单、安全且高效的方式。

Pod

基于Pod的服务发现配置使用kubernetes_sd_configs中的role字段设置为pod。这样设置后，Prometheus将从Kubernetes API中获取有关Pod的信息，然后根据所提供的标签选择要监视的Pod。通常，可以使用标签选择器来筛选要监视的Pod，例如，通过标签选择器可以选择特定应用程序、环境或者其他特定的标识符。

以下是一个简单的示例配置，演示如何在Prometheus中使用kubernetes_sd_configs基于Pod进行服务发现：

scrape_configs:
  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        action: keep
        regex: myapp

在这个示例中，Prometheus配置了一个作业（job），命名为kubernetes-pods，它使用kubernetes_sd_configs进行服务发现，配置中的role设置为pod。在relable_configs部分，使用source_labels指定了一个标签app，并通过正则表达式myapp筛选出了符合条件的Pod。这样，Prometheus就会监视所有带有app=myapp标签的Pod。

通过这种方式，基于Pod的服务发现可以让Prometheus自动发现和监视Kubernetes集群中的新Pod，并根据标签进行灵活的筛选和配置。

范例

  • 以下配置来自基于helm部署的Prometheus
scrape_configs:
- honor_labels: true
      job_name: kubernetes-pods
      kubernetes_sd_configs:
      - role: pod
      relabel_configs:
      - action: keep
        regex: true
        source_labels:
        - __meta_kubernetes_pod_annotation_prometheus_io_scrape
      - action: drop
        regex: true
        source_labels:
        - __meta_kubernetes_pod_annotation_prometheus_io_scrape_slow
      - action: replace
        regex: (https?)
        source_labels:
        - __meta_kubernetes_pod_annotation_prometheus_io_scheme
        target_label: __scheme__
      - action: replace
        regex: (.+)
        source_labels:
        - __meta_kubernetes_pod_annotation_prometheus_io_path
        target_label: __metrics_path__
      - action: replace
        regex: (\d+);(([A-Fa-f0-9]{1,4}::?){1,7}[A-Fa-f0-9]{1,4})
        replacement: '[$2]:$1'
        source_labels:
        - __meta_kubernetes_pod_annotation_prometheus_io_port
        - __meta_kubernetes_pod_ip
        target_label: __address__
      - action: replace
        regex: (\d+);((([0-9]+?)(\.|$)){4})
        replacement: $2:$1
        source_labels:
        - __meta_kubernetes_pod_annotation_prometheus_io_port
        - __meta_kubernetes_pod_ip
        target_label: __address__
      - action: labelmap
        regex: __meta_kubernetes_pod_annotation_prometheus_io_param_(.+)
        replacement: __param_$1
      - action: labelmap
        regex: __meta_kubernetes_pod_label_(.+)
      - action: replace
        source_labels:
        - __meta_kubernetes_namespace
        target_label: namespace
      - action: replace
        source_labels:
        - __meta_kubernetes_pod_name
        target_label: pod
      - action: drop
        regex: Pending|Succeeded|Failed|Completed
        source_labels:
        - __meta_kubernetes_pod_phase
      - action: replace
        source_labels:
        - __meta_kubernetes_pod_node_name
        target_label: node

这是一个Prometheus的配置示例，用于在Kubernetes集群中发现和监控Pod。让我解释一下这个配置的各个部分：

  1. honor_labels: true：表示Prometheus应该尊重从服务发现源（比如Kubernetes）获取到的标签。

  2. job_name: kubernetes-pods：定义了这个作业（job）的名称为kubernetes-pods，这个作业用于监控Kubernetes中的Pod。

  3. kubernetes_sd_configs：指定了使用Kubernetes服务发现配置，role: pod表示Prometheus将会从Kubernetes API中获取Pod的信息。

  4. relabel_configs：对获取到的标签进行处理的规则列表。

    • action: keep：保留满足条件的目标。

      • regex: true：正则表达式，表示如果Pod的注解prometheus.io/scrape存在并为true，则保留该目标。
      • source_labels: __meta_kubernetes_pod_annotation_prometheus_io_scrape：指定了标签的来源，这里是Pod的注解prometheus.io/scrape。

    • action: drop：丢弃满足条件的目标。

      • regex: true：正则表达式，表示如果Pod的注解prometheus.io/scrape_slow存在并为true，则丢弃该目标。
      • source_labels: __meta_kubernetes_pod_annotation_prometheus_io_scrape_slow：指定了标签的来源，这里是Pod的注解prometheus.io/scrape_slow。

    • action: replace：替换标签的值。

      • regex: (https?)：匹配http或https。

      • source_labels: __meta_kubernetes_pod_annotation_prometheus_io_scheme：指定了标签的来源，这里是Pod的注解prometheus.io/scheme。

      • target_label: __scheme__：将匹配到的值替换为__scheme__标签的值。

      • regex: (.+)：匹配任意字符。

      • source_labels: __meta_kubernetes_pod_annotation_prometheus_io_path：指定了标签的来源，这里是Pod的注解prometheus.io/path。

      • target_label: __metrics_path__：将匹配到的值替换为__metrics_path__标签的值。

      • regex: (\d+);(([A-Fa-f0-9]{1,4}::?){1,7}[A-Fa-f0-9]{1,4})：匹配端口和IPv6地址。

      • replacement: '[$2]:$1'：替换标签的值。

      • source_labels: __meta_kubernetes_pod_annotation_prometheus_io_port、__meta_kubernetes_pod_ip：指定了标签的来源，这里是Pod的注解prometheus.io/port和Pod的IP地址。

      • target_label: __address__：将匹配到的值替换为__address__标签的值。

    • action: labelmap：为标签添加前缀。

      • regex: __meta_kubernetes_pod_annotation_prometheus_io_param_(.+)：匹配注解prometheus.io/param_后面的内容。

      • replacement: __param_$1：添加前缀__param_。

      • regex: __meta_kubernetes_pod_label_(.+)：匹配标签__meta_kubernetes_pod_label_后面的内容。

      • replacement: __label_$1：添加前缀__label_。

    • action: drop：丢弃满足条件的目标。

      • regex: Pending|Succeeded|Failed|Completed：匹配状态为Pending、Succeeded、Failed或Completed的Pod。
      • source_labels: __meta_kubernetes_pod_phase：指定了标签的来源，这里是Pod的状态。

    • action: replace：替换标签的值。

      • source_labels: __meta_kubernetes_pod_node_name：指定了标签的来源，这里是Pod所在的节点的名称。
      • target_label: node：将匹配到的值替换为node标签的值。

这个配置文件的作用是从Kubernetes中发现符合条件的Pod，并根据其注解和标签，设置相应的目标配置，以便Prometheus可以监控这些Pod。

consul_sd_configs

基于 Consul 的服务发现

Prometheus 支持通过 Consul 实现服务发现。Consul 是一个用于服务发现和配置的工具，Prometheus 可以通过查询 Consul 来获取当前运行的服务实例信息。

Consul 是一个用于服务发现、健康检查和分布式配置的工具，由HashiCorp开发和维护。它被广泛用于构建和管理微服务架构的应用程序。下面是基于 Consul 的服务发现的详细解释：

1. Consul 服务发现的基本概念：

  • 服务注册： 微服务应用在启动时会向 Consul 注册自己的元数据（服务名称、IP 地址、端口等）。

  • 服务发现： Consul 提供了一个查询接口，允许其他服务或客户端查询可用的服务实例。

  • 健康检查： Consul 定期对服务进行健康检查，确保只有健康的服务实例会被提供给消费者。

2. Prometheus 使用 Consul 进行服务发现：

在 Prometheus 中，你可以配置 Consul 作为服务发现的目标。以下是相关步骤：

  • 配置文件： 在 Prometheus 的配置文件中，你需要指定 Consul 作为服务发现的目标。这通常涉及到定义 consul_sd_configs 部分，其中包含 Consul 地址以及一些其他配置选项。

  • 示例配置：

    scrape_configs:
  - job_name: 'consul'
    consul_sd_configs:
      - server: 'localhost:8500'
        services: []

    上述配置表示 Prometheus 将通过 Consul API 查询所有服务的实例。

  • 标签和元数据： 当 Prometheus 查询 Consul 获取服务实例时，它会自动添加一些元数据（例如服务名称、节点名称等）作为 Prometheus 的标签。这些标签使得用户能够更好地组织和查询监控数据。

3. Consul 的其他特性：

  • 健康检查： Consul 具有强大的健康检查机制，它可以定期检查服务的运行状况。如果服务出现故障，Consul 将从服务发现列表中移除该服务。

  • 分布式锁： Consul 提供了分布式锁的支持，这在微服务架构中是一个有用的特性，用于协调和同步服务之间的操作。

  • 事件广播： Consul 支持事件广播，可以用于在服务状态变化时通知其他服务。

4. 注意事项：

  • Consul 安全性： 在生产环境中，确保 Consul 集群和服务之间的通信是安全的，可以使用加密、认证等机制来保护数据和通信。

  • Prometheus 配置： 了解如何正确配置 Prometheus 以与 Consul 集成，包括正确设置 Consul 地址和授权信息。

通过使用 Consul 作为服务发现工具，Prometheus 可以更灵活地适应动态的微服务架构，并确保及时监控和采集有关服务实例的指标数据。

其他回答

Consul 是一个开源的服务发现和配置管理工具，由HashiCorp开发。它提供了服务发现、健康检查、键值存储、多数据中心支持等功能。在基于 Consul 的服务发现中，Prometheus 可以通过 Consul 的 HTTP API 主动查询服务实例的信息，从而实现自动化的监控。

以下是基于 Consul 的服务发现的详解：

  1. Consul Agent： Consul 集群中的每个节点都运行一个 Consul Agent，它负责维护节点的成员关系、处理健康检查、提供服务发现等功能。在要监控的节点上，Consul Agent 会注册服务并提供一个 HTTP API 供 Prometheus 查询。

  2. Service Registration（服务注册）： 当一个服务实例启动时，它的 Consul Agent 会向 Consul 集群注册服务。注册包含服务的名称、地址、端口以及其他与服务相关的元数据。这使得 Consul 集群知道有哪些服务实例可用。

  3. Health Checks（健康检查）： Consul 支持对服务实例进行健康检查，以确保只有健康的实例被提供给服务消费者。当服务实例的健康状态发生变化时，Consul 会更新该实例的状态。Prometheus 可以利用这些信息进行监控。

  4. Consul DNS Interface： Consul 提供了一个 DNS 接口，可以通过 DNS 查询服务的实例信息。Prometheus 可以使用这个 DNS 接口来进行服务发现。

  5. Prometheus 配置： 在 Prometheus 的配置文件中，你需要配置一个 consul_sd_configs 部分，以告诉 Prometheus 在哪里找到 Consul 集群以及需要监控的服务。以下是一个简化的例子：

    scrape_configs:
  - job_name: 'consul'
    consul_sd_configs:
      - server: 'consul-server-address'
        token: 'consul-access-token'  # 如果有的话
        services: ['your-service-name']

    这个配置告诉 Prometheus 在 Consul 集群的指定地址查询服务发现信息，并监控名为 ‘your-service-name’ 的服务。

  6. 自动服务发现： 由于 Consul 是动态的，当新的服务实例启动或旧的服务实例终止时，Consul 会自动更新服务注册信息。这使得 Prometheus 能够实时获得最新的服务发现信息，而无需手动配置。

总体而言，基于 Consul 的服务发现为 Prometheus 提供了一种灵活而自动化的方式来监控动态的服务实例。这样的架构使得监控系统能够适应现代分布式系统中服务的动态性和规模的变化。

ec2_sd_configs

基于 EC2 的服务发现

当运行在 AWS 上时，Prometheus 可以通过 EC2 标签和 AWS 的服务发现功能来自动检测和监控实例。

基于 EC2 的服务发现通常涉及到使用 AWS (Amazon Web Services) 提供的一些服务和功能来实现。在这种情况下，Prometheus 可以通过 EC2 实例的标签或 AWS 的服务发现功能来实现自动化的监控。以下是基于 EC2 的服务发现的详细解释：

  1. EC2 实例标签： 你可以在启动 EC2 实例时为其添加标签，标签可以包含自定义的键值对。Prometheus 可以通过查询 EC2 API 来获取这些标签，并根据标签信息自动发现和监控实例。以下是一个 Prometheus 配置的简化例子：

    scrape_configs:
  - job_name: 'ec2-instance-discovery'
    ec2_sd_configs:
      - region: 'your-aws-region'
        access_key: 'your-access-key'
        secret_key: 'your-secret-key'
        port: 9100  # 监控的端口
    relabel_configs:
      - source_labels: [__meta_ec2_tag_Name]
        target_label: instance

    这个配置告诉 Prometheus 使用 EC2 服务发现，从指定的 AWS 区域获取所有带有标签 “Name” 的实例，并将其标签值作为实例的标签。

  2. AWS 服务发现： AWS 提供了服务发现的功能，称为 AWS Cloud Map 或 AWS Service Discovery。使用这个功能，你可以为运行在 EC2 实例上的服务注册服务实例，并通过 DNS 查询实现服务发现。Prometheus 可以利用这个 DNS 接口来进行服务发现，从而监控实例。

  3. 自动标签更新： EC2 实例的标签可以在运行时动态变化。Prometheus 可以定期查询 EC2 API，以获取最新的实例标签信息。这使得监控系统能够适应实例的动态性和规模的变化。

  4. 健康检查： 你还可以使用 EC2 实例状态检查来确定实例的健康状况。Prometheus 可以根据实例的健康状态动态更新监控目标。

  5. IAM 角色： 为了访问 EC2 API，Prometheus 需要具有适当的 AWS Identity and Access Management (IAM) 角色。确保 Prometheus 的执行角色具有足够的权限来查询 EC2 实例的信息。

总体而言，基于 EC2 的服务发现使得 Prometheus 能够自动监控运行在 AWS 环境中的实例。无论实例是静态的还是动态的，Prometheus 都可以通过 EC2 实例的标签或 AWS 提供的服务发现功能来实现自动化的监控。

dns_sd_configs

基于 DNS 的服务发现

基于 DNS 的服务发现是一种常见的服务发现方式，尤其适用于需要通过 DNS 查询来获取服务实例信息的场景。在这种情况下，服务的地址和端口等信息可以通过 DNS 记录动态地提供给监控系统，如 Prometheus。以下是基于 DNS 的服务发现的详细解释：

  1. DNS SRV 记录： 在基于 DNS 的服务发现中，服务通常会使用 DNS SRV（Service）记录进行注册。SRV 记录包含有关服务的信息，例如服务的名称、协议、域名和端口。对于 Prometheus，SRV 记录提供了一种标准化的方式来指定服务的位置。

  2. Prometheus 配置： 在 Prometheus 的配置文件中，你需要配置一个 dns_sd_configs 部分，以指定要使用的 DNS 服务器和服务的域名。以下是一个简化的例子：

    scrape_configs:
  - job_name: 'dns-service-discovery'
    dns_sd_configs:
      - names:
          - 'your-service-name.your-domain.com'
        type: 'SRV'
        port: 80  # 服务的默认端口

    这个配置告诉 Prometheus 使用 DNS 服务发现来监控位于 ‘your-service-name.your-domain.com’ 域中的服务。

  3. 自动化更新： 当服务的实例发生变化时，DNS 服务器会自动更新 SRV 记录。Prometheus 会定期查询 DNS 服务器，以获取最新的服务实例信息。这意味着你可以通过 DNS 动态地添加或删除服务实例，而无需手动更新 Prometheus 配置。

  4. 标签和过滤： 你可以使用 DNS 记录中的信息来标识和过滤服务实例。例如，可以使用域名中的子域或 SRV 记录中的其他信息作为 Prometheus 中的标签。

  5. 多种 DNS 解决方案： Prometheus 支持不同的 DNS 解决方案，包括直接查询 DNS 服务器、使用本地 DNS 缓存或者集成到某些云提供商的 DNS 服务。

基于 DNS 的服务发现使得 Prometheus 能够自动地监控服务实例，并且在服务实例发生变化时无需手动配置。这种方式适用于许多不同的环境，特别是在服务注册和发现采用 DNS 的系统中。

示例1

scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['localhost:9100']  # Node Exporter 的默认端口

  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']  # Prometheus 自身的端口

示例2

# 还应该将Alertmanager程序作为监控目标，例如将如下配置添加到scrape_configs中
scrape_configs:
...
  - job_name: 'alertmanager'
    file_sd_configs:
    - files:
      - targets/prometheus/alertmanager*.yaml
 
 
 # /monitor/prometheus/targets/prometheus/alertmanager.yaml
- targets:
  - 10.0.0.8:9093
  labels:
    app: alertmanager

rule_files

定义告警规则，定义成功的告警规则，可通过 Prometheus UI 中的 Alerts 或 Status –> Rules 查看

https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/

为了能够让 Prometheus 能够启用定义的告警规则，需要在 Prometheus 全局配置文件中通过 rule_files 指定一组告警规则文件的访问路径，Prometheus 启动后会自动扫描这些路径下规则文件中定义的内容，并且根据这些规则计算是否向外部发送通知：

rule_files:
  - /etc/config/alerting_rules*.yml # 通常为绝对路径，支持通配符

默认情况下 Prometheus 会每分钟对这些告警规则进行计算，如果用户想定义自己的告警计算周期，则可以通过evaluation_interval 来覆盖默认的计算周期：

global:
  evaluation_interval: 2m

告警规则文件定义，在告警规则文件（例如 /etc/config/alerting_rules.yml）中，可以将一组相关的规则设置定义在一个 group 下。在每一个 group 中我们可以定义多个告警规则 (rule)。一条告警规则主要由以下几部分组成：

groups: # 规则组，可以将类似的规则划分到一个规则组中
- name: example  # 规则组的名称
  interval: 15 # 可选参数，多久执行一次规则，如果不配置默认去 global 的 evaluation_interval
    limit: 0 # 可选参数，总共执行多少次，默认0不限制
  rules:
  - alert: NodeMemoryUsage # 告警规则的名称，此段内容会作为邮件标题的首字段，标题后面字段会由默认的labels以及自定义的labels组成。
    expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 20 # 基于PromQL表达式告警触发条件，用于计算是否有时间序列满足该条件（布尔表达式，返回值为true触发报警，返回值为false不会触发报警），可以使用由Recording rule定义的指标。
    for: 1m # 可选参数（default = 0s），评估等待时间，用于表示只有当触发条件持续一段时间后才发送告警。在等待期间新产生告警的状态为pending。（控制在触发告警之前，测试表达式的值必须为true的时长）
    labels: #  告警规则被激活时，相关时间序列上的所有标签都会添加到生成告警实例之上，而labels则允许用户在告警上附加其它自定义的标签，标签值支持模板化，键只支持英文。
      serverity: critical
    annotations: # 用于指定一组附加信息，比如用于描述告警详细信息的文字等，annotations的内容在告警产生时会一同作为参数发送到Alertmanager，标签值支持模板化，键只支持英文。
      summary: "{{$labels.instance}}: High Memory usage detected"
      description: "{{$labels.instance}}: Memory usage is above 20% (current value is:{{ $value }})"
  • 语法检查：promtool check rules /path/to/example.rules.yml

blackbox_exporter

http

# /etc/config/alerting_rules_http.yml
groups: 
- name: BlackboxHttpMonitor
  rules:
  - alert: BlackboxSlowProbe
    expr: avg_over_time(probe_duration_seconds[1m]) > 1
    for: 30m
    labels:
      severity: warning
    annotations:
      summary: telnet (instance {{ $labels.instance }}) 超时1秒
      description: "VALUE = {{ $value }}n  LABELS = {{ $labels }}"
  - alert: BlackboxProbeHttpFailure
    expr: probe_http_status_code <= 199 OR probe_http_status_code >= 400
    for: 30m
    labels:
      severity: critical
    annotations:
      summary: HTTP 状态码 (instance {{ $labels.instance }})
      description: "HTTP status code is not 200-399  VALUE = {{ $value }}  LABELS = {{ $labels }}"
  - alert: BlackboxSslCertificateWillExpireSoon
    expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 30
    for: 30m
    labels:
      severity: warning
    annotations:
      summary:  域名证书即将过期 (instance {{ $labels.instance }})
      description: "域名证书30天后过期n  VALUE = {{ $value }}n  LABELS = {{ $labels }}"
  - alert: BlackboxSslCertificateWillExpireSoon
    expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 7
    for: 30m
    labels:
      severity: critical
    annotations:
      summary: 域名证书即将过期 (instance {{ $labels.instance }})
      description: "域名证书7天后过期n VALUE = {{ $value }}n  LABELS = {{ $labels }}"
  - alert: BlackboxSslCertificateExpired
    expr: probe_ssl_earliest_cert_expiry - time() <= 0
    for: 30m
    labels:
      severity: critical
    annotations:
      summary: 域名证书已过期 (instance {{ $labels.instance }})
      description: "域名证书已过期n  VALUE = {{ $value }}n  LABELS = {{ $labels }}"
  - alert: BlackboxProbeSlowHttp
    expr: avg_over_time(probe_http_duration_seconds[1m]) > 10
    for: 1m
    labels:
      severity: warning
    annotations:
      summary: HTTP请求超时 (instance {{ $labels.instance }})
      description: "HTTP请求超时超过10秒n  VALUE = {{ $value }}n  LABELS = {{ $labels }}"

mysql_exporter

# /etc/config/alerting_rules_mysql.yml
groups:
- name: MySQL 
  rules:
  - alert: MySQLRunningStatus
    expr: mysql_up == 0
    for: 1m
    labels:
      serverity: critical
    annotations:
      summary: "{{$labels.instance}}: MySQL downtime"
      description: "{{$labels.instance}}: MySQL downtime (current value is:{{ $value }})"

node_exporter

# 修改prometheus.yml文件，配置告警规则文件host.yml：
rule_files:
  - /etc/prometheus/rule_files/host.yml
 
 
# 创建文件/usr/local/prometheus/rule_files/host.yml，内容如下
groups:
- name: Host
  rules:
  - alert: HostCPU
    expr: 100 * (1 - avg(irate(node_cpu_seconds_total{mode="idle"}[2m])) by(instance)) > 80
    for: 5m
    labels:
      serverity: high
    annotations:
      summary: "{{$labels.instance}}: High CPU Usage Detected"
      description: "{{$labels.instance}}: CPU usage is {{$value}}, above 80%"

  - alert: HostMemory
    expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 80
    for: 5m
    labels:
      serverity: middle
    annotations:
      summary: "{{$labels.instance}}: High Memory Usage Detected"
      description: "{{$labels.instance}}: Memory Usage i{{ $value }}, above 80%"

  - alert: HostDisk
    expr: 100 * (node_filesystem_size_bytes{fstype=~"xfs|ext4"} - node_filesystem_available_bytes) / node_filesystem_size_bytes > 80
    for: 5m
    labels:
      serverity: low
    annotations:
      summary: "{{$labels.instance}}: High Disk Usage Detected"
      description: "{{$labels.instance}}, mountpoint {{$labels.mountpoint}}: Disk Usage is {{ $value }}, above 80%"

Example

文件说明

groups:
- name: pod_rules
  rules:
  # 对于请求延迟中值大于1秒的任何实例发出警报。
  - alert: APIHighRequestLatency
    expr: api_http_request_latencies_second{quantile="0.5"} > 1
    for: 10m
    annotations:
      summary: "High request latency on {{ $labels.instance }}"
      description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"

节点核心指标搜集模板

  • 有问题
groups:
- name: node_rules
  rules:
  - alert: Disk_Used
    expr: (node_filesystem_size_bytes{instance=~"$instance:.+",fstype=~"ext.*|xfs|nfs",mountpoint !~".*pod.*"}-node_filesystem_free_bytes{instance=~"$instance:.+",fstype=~"ext.*|xfs|nfs",mountpoint !~".*pod.*"}) *100/(node_filesystem_avail_bytes {instance=~"$instance:.+",fstype=~"ext.*|xfs|nfs",mountpoint !~".*pod.*"}+(node_filesystem_size_bytes{instance=~"$instance:.+",fstype=~"ext.*|xfs|nfs",mountpoint !~".*pod.*"}-node_filesystem_free_bytes{instance=~"$instance:.+",fstype=~"ext.*|xfs|nfs",mountpoint !~".*pod.*"})) > 50
    for: 1m
    labels:
      severity: page
    annotations:
      summary: "node节点磁盘利用率警告"
      description: "{{ $labels.instance }} 222 {{ $labels.job }} 磁盘利用率超过50%"

xxx模板

  • /usr/local/prometheus/pod_rules.yml
groups:
- name: example
  rules:
  - alert: InstanceDown
    expr: up == 0
    for: 5m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."
  - alert: APIHighRequestLatency
    expr: api_http_request_latencies_second{quantile="0.5"} > 1
    for: 10m
    annotations:
      summary: "High request latency on {{ $labels.instance }}"
      description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"

5xx检测模板

groups:
  - name: demo-service-alerts
    rules:
      - alert: Many5xxErrors
        expr: |
          (
            sum by(path, instance, job) (
              rate(demo_api_request_duration_seconds_count{status=~"5..",job="demo"}[1m])
            )
          /
            sum by(path, instance, job) (
              rate(demo_api_request_duration_seconds_count{job="demo"}[1m])
            ) * 100 > 0.5
          )
        for: 30s
        labels:
          severity: critical
        annotations:
          title: "{{$labels.instance}} high 5xx rate on {{$labels.path}}"
          description: "The 5xx error rate for path {{$labels.path}} on {{$labels.instance}} is {{$value}}%."

HighCPUUsage

groups:
  - name: example-alerts
    rules:
      - alert: HighCPUUsage
        expr: node_cpu_seconds_total / node_uptime_seconds * 100 > 90
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "High CPU usage detected"
          description: "CPU usage on instance {{ $labels.instance }} is above 90% for 5 minutes."

alerting

  • 指定 Alertmanager 的地址，以便将警报传递给 Alertmanager
alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager.monitoring.svc.cluster.local:9093']

remote_write

remote_write:
  - url: 'http://remote-write-endpoint/write'

remote_read

remote_read:
  - url: 'http://remote-read-endpoint/read'

storage

storage:
  tsdb:
    path: '/prometheus/data'
    retention_time: '30d'

—

label 概述

在Prometheus中，标签在组织和查询指标方面起着至关重要的作用。

以下是关于Prometheus标签的概述：

  1. 指标中的标签：

    • Prometheus指标是键值对，标签用于为这些指标提供额外的维度。
    • 标签有助于区分同一指标的不同实例。例如，在监视多个服务实例时，可以使用标签来区分它们。

  2. 选择器和查询：

    • 标签在使用PromQL（Prometheus查询语言）查询指标时非常重要。
    • 选择器可用于根据特定标签值过滤和聚合指标，从而实现更加细粒度和有针对性的监控。

  3. 服务发现：

    • 标签通常用于服务发现机制。Prometheus可以基于标签动态发现目标，轻松监视变化的环境，例如Kubernetes等容器编排平台。

  4. 标签重命名：

    • Prometheus允许对指标进行标签重命名，即在存储之前修改或添加标签。这对于规范化和保持指标名称的一致性非常有用。

  5. 警报：

    • 标签在定义警报规则方面起着重要作用。可以配置警报以根据特定条件和标签值触发，提供在设置警报机制时的灵活性。

  6. 基数：

    • 尽管标签增强了灵活性，但管理标签基数很重要。基数高（大量不同的标签值）可能会影响性能和存储需求。在设计标签模式时需要谨慎考虑。

  7. 最佳实践：

    • 设计明智而高效的标签模式对于有效监控至关重要。在定义标签时，考虑用例、潜在查询和服务发现的需求。

总而言之，Prometheus标签对于向指标添加上下文和具体性，实现Prometheus监控系统中强大的查询、服务发现和警报功能至关重要。

常见共有 label

instance

instance 标签用于标识被监控实例的唯一标识符，通常是主机名或IP地址。这个标签提供了有关指标来源的关键信息，使得可以在查询和筛选中更精确地指定特定实例的指标。

以下是一个示例，展示如何使用 instance 标签：

http_requests_total{job="webserver", instance="example.com:8080", endpoint="/metrics"}

在上面的示例中，instance 标签的值是 “example.com:8080”，表示这个指标是从名为 “webserver” 的作业中的具体实例 “example.com:8080” 上提取的。这可以是主机名和端口的组合，也可以是其他唯一标识实例的信息。

重要的是，instance 标签允许Prometheus区分和监控多个相同作业的不同实例。这对于在分布式环境中监控多个相同服务的实例非常有用，例如在容器编排系统（如Kubernetes）中。

在标签模式设计中，确保 instance 标签的值足够唯一以标识每个被监控的实例，以便能够精确地查询和区分不同的实例。这对于实现细粒度的监控和故障排除非常重要。

job

job 标签用于标识执行相同工作的一组目标实例。这个标签通常用于区分不同的作业，其中作业可以是一组具有相似功能或角色的实例的集合。

以下是一个示例，展示如何使用 job 标签：

http_requests_total{job="webserver", instance="example.com:8080", endpoint="/metrics"}

在上面的示例中，job 标签的值是 “webserver”，表示这个指标属于名为 “webserver” 的作业。作业通常表示一组相似的任务或服务，可能是一个应用程序的不同组件或一个服务的不同实例。

关键点包括：

  1. 功能区分： job 标签有助于将相似功能的实例组织在一起。例如，可能有一个 “webserver” 作业用于监控所有Web服务器的实例。

  2. 查询和警报： 使用 job 标签可以轻松地执行与特定作业相关的查询和设置作业级别的警报规则。这增加了在监控系统中组织和管理指标的灵活性。

  3. 服务发现： job 标签通常与服务发现机制结合使用，以便Prometheus可以动态发现和监控相同作业的新实例。

确保在定义 job 标签时，考虑到作业的逻辑组织结构，以便在查询和警报设置中能够方便地区分不同作业。这有助于实现更清晰、有层次结构的监控体系结构。

endpoint

endpoint 标签通常用于标识被监控实例的服务端点（endpoint）。这个标签提供了有关从实例中提取的指标的服务端点的信息。服务端点是指实例上暴露指标的具体路径或端口。

以下是一个示例，展示如何使用 endpoint 标签：

http_requests_total{job="webserver", instance="example.com:8080", endpoint="/metrics"}

在上面的示例中，endpoint 标签的值是 “/metrics”，表示这个指标是从 “/metrics” 端点上提取的。这对于在监控系统中更细致地区分不同服务端点的指标非常有用。

需要注意的是，endpoint 标签的具体使用可能会因监控配置和标签模式而有所不同。这个标签通常是在配置文件中定义的，以反映被监控实例上的服务结构。

在设计标签模式时，考虑如何使用 endpoint 标签可以使查询更有针对性，同时提供有关服务端点的有用信息。

以 __ 为前缀的标签

在 Prometheus 中，以 __（双下划线）为前缀的标签通常是 Prometheus 自己生成或添加的元信息标签，用于提供有关指标和监控目标的额外信息。这些标签通常不是用户定义的，而是由 Prometheus 在抓取和处理数据时自动生成的。以下是一些常见的以 __ 为前缀的标签及其含义：

  1. __name__： 这个标签包含了指标的名称。在 Prometheus 中，每个时间序列都与一个唯一的指标名称相关联。__name__ 标签指示了该时间序列属于哪个指标。

  2. __meta_*： 以 __meta_ 为前缀的标签是在服务发现阶段添加的元信息标签。这些标签包含了有关监控目标的元信息，例如实例的 IP 地址、端口、作业名称等。例如，__meta_instance 可能包含目标实例的 IP 地址。

  3. __address__： 这个标签包含了监控目标的地址信息。通常，它是实例的 IP 地址和端口的组合，例如 10.0.0.1:9090。

  4. __scheme__： 该标签包含了用于与目标建立连接的协议方案，例如 http 或 https。

  5. __metrics_path__： 该标签包含了用于抓取指标数据的路径。对于 HTTP 协议，这通常是 /metrics。

这些以 __ 为前缀的标签提供了有关监控目标和指标数据的重要信息，Prometheus 使用它们来标识和区分不同的时间序列。在配置中，你通常不需要手动定义或修改这些标签，而是利用它们来进行灵活的目标和指标数据的处理。例如，在 relabel_configs 中，你可能会使用 __meta_* 标签来进行条件性的目标过滤或修改。

relabel 概述

relabel 在 Prometheus 中的作用是在采集数据之前对目标标签进行修改、过滤和重命名。

通过 relabel 配置，你可以动态地调整监控目标的标签，使其更符合你的需求，或者根据条件进行过滤，选择性地采集数据。

可 relabel 的阶段

可以通过 relabel_configs 和 metric_relabel_configs 这两个配置进行不同阶段的 relabel

relabel_configs 主要用于目标级别的标签操作，而 metric_relabel_configs 则用于指标级别的操作。这两者结合使用，可以在 Prometheus 配置中对目标和指标数据进行更加灵活的调整和过滤。

relabel_configs 阶段

这个阶段在抓取目标之前执行，主要用于修改或过滤掉抓取配置中的标签。这些配置的主要作用是对整个目标进行操作，例如修改实例标签、添加额外的标签、删除不需要的标签等。

scrape_configs:
  - job_name: 'example-job'
    static_configs:
      - targets: ['example-target:9090']
    relabel_configs:
      - source_labels: ['__address__']
        target_label: 'instance'
        regex: '(.+):\\d+'
        replacement: '$1'

在这个例子中，relabel_configs 用于在抓取配置中的静态目标中修改 __address__ 标签，去除端口信息并将结果赋给新的 instance 标签。

metric_relabel_configs 阶段

这个阶段在抓取的指标数据被处理之前（数据存储和查询之前）执行。

它用于对具体的指标进行修改，例如修改指标的名称、标签的名称、标签的值等。这些配置的主要作用是对指标数据进行操作，而不涉及整个目标的修改。

metric_relabel_configs:
  - source_labels: ['job']
    regex: 'unwanted-job'
    action: drop

在这个例子中，metric_relabel_configs 用于在抓取的指标数据中，删除包含特定 job 标签值的指标数据。

抓取的指标数据被处理之前执行，其中的被处理之前是什么意思？

抓取的指标数据被处理之前指的是在 Prometheus 存储或显示指标数据之前，即在将指标数据存入时间序列数据库之前。在这个阶段，Prometheus 可以对抓取到的原始指标数据进行一些调整、修改或过滤。

具体来说，metric_relabel_configs 在抓取的时候应用于每个抓取到的样本，可以对样本的标签或值进行调整。这样的处理发生在 Prometheus 将数据存储到时间序列数据库之前，也在数据被查询或展示之前。

下面是一个例子，演示了在 metric_relabel_configs 阶段删除某个标签的配置：

scrape_configs:
  - job_name: 'example-job'
    static_configs:
      - targets: ['example-target:9090']
    metric_relabel_configs:
      - source_labels: ['job']
        regex: 'unwanted-job'
        action: drop

在这个例子中，如果样本的 job 标签匹配正则表达式 ‘unwanted-job’，那么这个样本将被删除（action: drop）。这样的操作在指标数据被存储之前发生，因此称为在抓取的指标数据被处理之前执行。

参考文档

https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config

Prometheus 的 relabel 功能是一种非常强大的标签重标定和过滤机制，它允许你在采集数据之前对目标标签进行修改、删除或添加。relabel 配置是在 Prometheus 配置文件中的作业（job）或抓取配置中定义的。

以下是 relabel 的一些主要概念和用法：

  1. 目标标签（Target Labels）： 目标标签是在目标（通常是监控目标，如服务实例）上附加的标签，用于标识和分类目标。这些标签通常由服务发现或静态配置提供。relabel 允许你在采集数据之前修改目标标签。

  2. relabel 配置块： relabel 配置是在 Prometheus 配置文件中的 scrape_configs 中的 relabel_configs 部分定义的。这个配置块包含一系列的规则，每个规则都描述了对目标标签的操作。

    scrape_configs:
  - job_name: 'example-job'
    static_configs:
      - targets: ['example-target:9090']
    relabel_configs:
      - source_labels: ['__address__']
        target_label: 'instance'
        replacement: 'new-instance-name'

    在这个例子中，relabel 配置将目标标签 __address__ 的值复制到新的标签 instance 中，并用新的值 new-instance-name 替换。

  3. source_labels 和 target_label： source_labels 定义了一个或多个用于生成新标签值的源标签，而 target_label 定义了生成的新标签的名称。

  4. 正则表达式替换： replacement 字段可以使用正则表达式替换源标签的值。这在需要动态更改标签值时非常有用。

    relabel_configs:
  - source_labels: ['__address__']
    target_label: 'instance'
    regex: '(.+):\\d+'
    replacement: '$1'

    在这个例子中，正则表达式 (.+):\\d+ 从 __address__ 中提取主机名，并将其放入新的标签 instance 中。

  5. 过滤目标： 通过设置 action 为 drop，可以在 relabel 中删除不符合条件的目标。这允许你根据一些条件来选择性地过滤掉某些目标。

    relabel_configs:
  - source_labels: ['job']
    regex: 'unwanted-job'
    action: drop

    在这个例子中，如果目标的 job 标签值匹配正则表达式 ‘unwanted-job’，则该目标将被丢弃。

relabel 提供了灵活的标签操作和过滤机制，使得你能够在采集数据之前对目标进行动态的、条件性的修改，以满足监控需求。这对于适应不同环境、动态服务发现和灵活的数据处理非常有用。

默认 label

# curl -s http://localhost:9090/api/v1/targets | jq
{
  "status": "success",
  "data": {
    "activeTargets": [
      {
        "discoveredLabels": { # relabel 前在服务发现期间检索到的未修改标签，对应于web界面的Before relabeling。
          "__address__": "localhost:9090",
          "__metrics_path__": "/metrics",
          "__scheme__": "http",
          "__scrape_interval__": "15s",
          "__scrape_timeout__": "10s",
          "job": "prometheus"
        },
        "labels": { # relabel 后的标签集，对应于web界面的Labels，
          "instance": "localhost:9090", # 该标签的内容对应到Target实例的 __address__，这里实际上是发生了一次标签的重写处理，而标签的内容是从 discoveredLabels 中获取的。
          "job": "prometheus"
        },
        "scrapePool": "prometheus",
        "scrapeUrl": "http://localhost:9090/metrics",
        "globalUrl": "http://local-test:9090/metrics",
        "lastError": "",
        "lastScrape": "2024-01-26T17:32:24.163436983+08:00",
        "lastScrapeDuration": 0.004034767,
        "health": "up",
        "scrapeInterval": "15s",
        "scrapeTimeout": "10s"
      }
    ],
    "droppedTargets": []
  }
}

relabel_configs

relabel_configs 配置说明：

# 源标签，没有经过relabel处理之前的标签名字；列表 可以指定多个
[ source_labels: '[' <labelname> [, ...] ']' ]


# 源标签的值的连接分隔符。默认是";"
[ separator: <string> | default = ; ]


# 通过relabel处理之后的标签名字，定义新标签时必须指定此项，只是删除源标签则无需指定此项
# 若在relabel的过程中需要临时存储标签值，则要使用__tmp标签名称为前缀进行保存，以避免同Prometheus的内建标签冲突；
[ target_label: <labelname> ]


# 默认使用正则匹配源标签的值。默认是(.*)
# 具体匹配标签名还是值取决于action，例如：使用labelmap时匹配的是标签名
[ regex: <regex> | default = (.*) ]


# 取源标签值散列的模数
[ modulus: <int> ]


# 通过分组替换后标签（target_label）对应的值。默认是$1
[ replacement: <string> | default = $1 ]


# 根据正则表达式匹配执行的动作（对目标标签的操作）。默认是replace
[ action: <relabel_action> | default = replace ]
# action 可用取值如下：
keep # 保持目标，不进行任何操作。
drop #  丢弃目标，不进行后续操作，相当于从抓取列表中删除该目标。
replace # 替换目标标签的值，使用正则表达式替换。
labelmap # 标签映射，用于将标签名称的一部分映射到新的标签。
labeldrop # 删除匹配正则表达式的标签。
hashmod # 使用哈希模数对目标进行分片。
labelkeep # 保留匹配正则表达式的标签，删除其他标签。

relabel_configs 生效位置，job级。

  • prometheus.yml
...
scrape_configs:
  - job_name: "prometheus"
    file_sd_configs:
    - files:
      - targets/prometheus/prometheus*.yaml
  - job_name: "node-exporter"
    file_sd_configs:
    - files:
      - targets/prometheus/node-exporter*.yaml
  - job_name: 'alertmanager'
    file_sd_configs:
    - files:
      - targets/prometheus/alertmanager*.yaml

    relabel_configs: # 与job_name对齐表示只对此job生效
    - source_labels:
      - "__scheme__"
      - "__address__"
      - "__metrics_path__"
      target_label: "address"
      regex: "(.*)"
      replacement: $1
      action: replace

keep

保持目标，不进行任何操作。

relabel_configs:
  - action: keep

keep

  • regex不能匹配到target上的source_labels上的各标签的串连值时，则删除该target；

在 Prometheus 的 relabel_configs 中，keep 操作用于保持目标，不进行任何修改或过滤。它是一种简单的操作，用于将特定的目标保留在抓取列表中，而不对其进行任何后续操作。以下是 keep 操作的详细解释：

relabel_configs:
  - action: keep

  • 作用： keep 操作的作用是保持目标在抓取列表中，不进行任何修改。这意味着该目标将按照配置继续进行数据抓取，而不会应用其他 relabel 规则。

  • 使用场景： 通常，keep 操作用于明确指定哪些目标应该保留在监控范围内，而不对其进行任何动态调整。例如，当使用服务发现机制自动发现监控目标时，可以使用 keep 操作来筛选出特定的目标。

  • 示例： 下面是一个示例，展示了如何使用 keep 操作来保持具有特定标签的目标：

    relabel_configs:
  - action: keep
    source_labels: ['environment']
    regex: 'production'

    在这个例子中，只有具有 environment 标签值为 production 的目标才会被保留，其他目标将被忽略。

keep 操作在配置中是一种简单而实用的方式，用于明确指定哪些目标应该保留在监控中，而不对其进行额外的操作。

drop

丢弃目标，不进行后续操作，相当于从抓取列表中删除该目标。

relabel_configs:
  - action: drop

drop

  • regex能匹配到target上的source_labels上的各标签的串连值时，则删除该target；

在 Prometheus 的 relabel_configs 中，drop 操作用于丢弃匹配规则的目标，从抓取列表中删除这些目标，使其不再被 Prometheus 抓取和监控。以下是 drop 操作的详细解释：

relabel_configs:
  - action: drop
    regex: 'unwanted-target.*'

  • 作用： drop 操作的主要作用是根据正则表达式匹配规则，删除抓取列表中匹配的目标。这意味着这些目标将不再被 Prometheus 抓取和监控。

  • 使用场景： drop 操作通常用于过滤掉不需要监控的目标，或者排除一些异常或临时的目标。通过使用正则表达式，可以精确地指定要丢弃的目标。

  • 示例： 下面是一个示例，展示了如何使用 drop 操作根据正则表达式删除具有特定标签值的目标：

    relabel_configs:
  - action: drop
    source_labels: ['job']
    regex: 'unwanted-job'

    在这个例子中，如果目标的 job 标签值匹配正则表达式 ‘unwanted-job’，则该目标将被删除，不再被 Prometheus 监控。

drop 操作允许在配置中动态地过滤掉一些目标，以确保 Prometheus 只监控和抓取感兴趣的目标。这在处理大规模监控环境或需要临时排除一些目标时非常有用。

目标过滤

通过 relabel 的 action 字段，你可以选择性地过滤掉不符合条件的目标。例如，你可以根据标签的某个值来过滤掉一些不需要监控的目标。

relabel_configs:
  - source_labels: ['job']
    regex: 'unwanted-job'
    action: drop

replace 替换标签值

替换目标标签的值，使用正则表达式替换。

relabel_configs:
  - action: replace
    source_labels: ['instance']
    target_label: 'new_instance'
    regex: '(.+):\\d+'
    replacement: '$1'

replace：首先将source_labels中指定的各标签的值进行串连，而后将regex字段中的正则表达式对源标签值进行匹配判定，若匹配，则将target_label字段中指定的标签的值替换为replacement字段中保存的值；

  • replacement可按需引用保存regex中的某个“分组模式”匹配到的值；默认保存整个regex匹配到的内容；
  • 进行值替换时，replacememnt字段中指定标签的值也支持以分组格式进行引用；

在 Prometheus 的 relabel_configs 中，replace 操作用于替换目标标签的值。这允许你通过正则表达式匹配和替换来修改目标的标签值。以下是 replace 操作的详细解释：

relabel_configs:
  - action: replace
    source_labels: ['instance']
    target_label: 'new_instance'
    regex: '(.+):\\d+'
    replacement: '$1'

  • 作用： replace 操作的主要作用是使用正则表达式匹配 source_labels 定义的源标签值，并将匹配的部分替换为 replacement 定义的内容，然后将结果赋给 target_label 定义的目标标签。这允许在采集数据之前对目标标签进行动态调整。

  • 使用场景： replace 操作通常用于调整目标标签的值，例如去除端口信息、重命名标签等。这在使标签更具描述性或符合特定规范时非常有用。

  • 示例： 下面是一个示例，展示了如何使用 replace 操作将 instance 标签中的端口信息去掉，并将结果赋给新的 new_instance 标签：

    relabel_configs:
  - action: replace
    source_labels: ['instance']
    target_label: 'new_instance'
    regex: '(.+):\\d+'
    replacement: '$1'

    在这个例子中，正则表达式 (.+):\\d+ 匹配了 instance 标签值中的 IP 地址和端口信息，然后使用 $1 来保留 IP 地址部分，将结果赋给新的 new_instance 标签。

replace 操作允许在采集数据之前对目标标签进行灵活的修改，适应不同的监控需求。这种操作在处理服务发现或动态环境时非常有用。

单 source_labels 替换

# 替换前
# curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | {discoveredLabels, labels}'
{
  "discoveredLabels": {
    "__address__": "localhost:9090",
    "__metrics_path__": "/metrics",
    "__scheme__": "http",
    "__scrape_interval__": "15s",
    "__scrape_timeout__": "10s",
    "job": "prometheus"
  },
  "labels": {
    "instance": "localhost:9090",
    "job": "prometheus"
  }
}



# 替换，下面的写法完全可以使用 labelmap 代替
scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]
    # relabel配置
    relabel_configs:
    - source_labels: # 指定要处理的源标签名称
      - "__address__" # 列表形式可以指定多个
      target_label: "address" # 自定义替换后的标签名
      regex: "(.*)" # 正则匹配源标签的内容，这里匹配全部内容
      replacement: ${1} # 指定要替换后的标签内容，来自regex:正则中定义的内容
      action: replace # 替换
 
 
 
# 替换后
# curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | {discoveredLabels, labels}'
{
  "discoveredLabels": {
    "__address__": "localhost:9090",
    "__metrics_path__": "/metrics",
    "__scheme__": "http",
    "__scrape_interval__": "15s",
    "__scrape_timeout__": "10s",
    "job": "prometheus"
  },
  "labels": {
    "address": "localhost:9090", # relabel 后出现的内容
    "instance": "localhost:9090",
    "job": "prometheus"
  }
}

多 source_labels 替换

多 source_labels 默认分隔符

  • 指定多个源标签时，多个标签值间 默认以 “;” 作为分隔符。
# 替换前
# curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | {discoveredLabels, labels}'
{
  "discoveredLabels": {
    "__address__": "localhost:9090",
    "__metrics_path__": "/metrics",
    "__scheme__": "http",
    "__scrape_interval__": "15s",
    "__scrape_timeout__": "10s",
    "job": "prometheus"
  },
  "labels": {
    "instance": "localhost:9090",
    "job": "prometheus"
  }
}


# 替换
scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]
    relabel_configs:
    - source_labels: # 指定多个源标签
      - "__scheme__"
      - "__address__"
      - "__metrics_path__"
      target_label: "endpoint"
      regex: "(.*)"
      replacement: ${1}
      action: replace


# 替换后
# curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | {discoveredLabels, labels}'
{
  "discoveredLabels": {
    "__address__": "localhost:9090",
    "__metrics_path__": "/metrics",
    "__scheme__": "http",
    "__scrape_interval__": "15s",
    "__scrape_timeout__": "10s",
    "job": "prometheus"
  },
  "labels": {
    "endpoint": "http;localhost:9090;/metrics", # 多个标签值间 默认以 ";" 作为分隔符。
    "instance": "localhost:9090",
    "job": "prometheus"
  }
}

使用默认分隔符

# 替换前
# curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | {discoveredLabels, labels}'
{
  "discoveredLabels": {
    "__address__": "localhost:9090",
    "__metrics_path__": "/metrics",
    "__scheme__": "http",
    "__scrape_interval__": "15s",
    "__scrape_timeout__": "10s",
    "job": "prometheus"
  },
  "labels": {
    "instance": "localhost:9090",
    "job": "prometheus"
  }
}


# 替换
scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]
    relabel_configs:
    - source_labels:
      - "__scheme__"
      - "__address__"
      - "__metrics_path__"
      target_label: "endpoint"
      regex: "(.*);(.*);(.*)" # 使用默认分隔符进行正则匹配
      replacement: ${1}://${2}${3}
      action: replace


# 替换后
# curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | {discoveredLabels, labels}'
{
  "discoveredLabels": {
    "__address__": "localhost:9090",
    "__metrics_path__": "/metrics",
    "__scheme__": "http",
    "__scrape_interval__": "15s",
    "__scrape_timeout__": "10s",
    "job": "prometheus"
  },
  "labels": {
    "endpoint": "http://localhost:9090/metrics", # relabel后的值
    "instance": "localhost:9090",
    "job": "prometheus"
  }
}

自定义默认分隔符

# 替换前
# curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | {discoveredLabels, labels}'
{
  "discoveredLabels": {
    "__address__": "localhost:9090",
    "__metrics_path__": "/metrics",
    "__scheme__": "http",
    "__scrape_interval__": "15s",
    "__scrape_timeout__": "10s",
    "job": "prometheus"
  },
  "labels": {
    "instance": "localhost:9090",
    "job": "prometheus"
  }
}


# 替换
scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]
    relabel_configs:
    - source_labels:
      - "__scheme__"
      - "__address__"
      - "__metrics_path__"
      target_label: "endpoint"
      regex: "(http|https)(.*)"
      separator: "" # 也可以将指定多个源标签时默认";"分隔符改为空值，然后定义regex时就无需加";"了
      replacement: "${1}://${2}"
      action: replace


# 替换后
# curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | {discoveredLabels, labels}'
{
  "discoveredLabels": {
    "__address__": "localhost:9090",
    "__metrics_path__": "/metrics",
    "__scheme__": "http",
    "__scrape_interval__": "15s",
    "__scrape_timeout__": "10s",
    "job": "prometheus"
  },
  "labels": {
    "endpoint": "http://localhost:9090/metrics", # relabel后的值
    "instance": "localhost:9090",
    "job": "prometheus"
  }
}

labelmap

标签映射，用于将标签名称的一部分映射到新的标签。

relabel_configs:
  - action: labelmap
    regex: __meta_(.+)

labelmap

  • 匹配regex所有标签名称，然后复制匹配标签的值进行分组，通过replacement分组引用($1,$2,…)替代；
  • 通常用于取出匹配的标签名的一部分生成新标签；
  • 注意：只能对 before relabeling 中的值加以处理？？？

labelmap 对所有的标签名进行匹配

在 Prometheus 的 relabel_configs 中，labelmap 操作用于将标签名称的一部分映射到新的标签。这允许你根据正则表达式匹配来动态生成新的标签。以下是 labelmap 操作的详细解释：

relabel_configs:
  - action: labelmap
    regex: __meta_(.+)

  • 作用： labelmap 操作的主要作用是根据正则表达式 regex 匹配的标签名称的一部分，生成新的标签。这通常用于从元信息标签中提取关键信息，以创建更有意义的标签。

  • 使用场景： labelmap 操作通常用于动态生成标签，以便更好地组织和标识监控数据。这对于处理元信息标签特别有用，因为它们通常包含有关监控目标的额外信息。

  • 示例： 下面是一个示例，展示了如何使用 labelmap 操作将以 __meta_ 前缀的标签映射为新的标签：

    relabel_configs:
  - action: labelmap
    regex: __meta_(.+)

    在这个例子中，正则表达式 __meta_(.+) 匹配以 __meta_ 前缀的标签名称，然后使用捕获组 (.+) 生成新的标签，该标签以 __meta_ 为前缀。

labelmap 操作允许在配置中根据正则表达式生成新的标签，从而更灵活地组织和处理监控数据。这有助于使标签更有意义，更符合组织规范。

demo - 1

# 替换前
# curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | {discoveredLabels, labels}'
{
  "discoveredLabels": {
    "__address__": "localhost:9090",
    "__metrics_path__": "/metrics",
    "__scheme__": "http",
    "__scrape_interval__": "15s",
    "__scrape_timeout__": "10s",
    "job": "prometheus"
  },
  "labels": {
    "instance": "localhost:9090",
    "job": "prometheus"
  }
}


# 替换，单 source_labels 替换的改进版
scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]
    # relabel配置
    relabel_configs:
      - regex: "__(address)__" #  使用正则表达式匹配标签名称
        replacement: "ip_${1}" #  当匹配成功时，将使用 "ip_" 前缀和匹配的内容 ${1} 替换标签名称。
        action: labelmap # 执行 labelmap 操作，这将在抓取时生成一个新的标签映射。

 
# 替换后
# curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | {discoveredLabels, labels}'
{
  "discoveredLabels": {
    "__address__": "localhost:9090",
    "__metrics_path__": "/metrics",
    "__scheme__": "http",
    "__scrape_interval__": "15s",
    "__scrape_timeout__": "10s",
    "job": "prometheus"
  },
  "labels": {
    "instance": "localhost:9090",
    "ip_address": "localhost:9090", # relabel 后出现的内容
    "job": "prometheus"
  }
}

replace 和 labelmap 的区别

在 Prometheus 的 relabel_configs 中，replace 和 labelmap 是两种不同的操作，用于对目标标签进行修改。下面是它们的区别详解：

replace 操作：

  • 作用： replace 操作用于通过正则表达式匹配源标签值，并使用替换值来修改目标标签值。

  • 示例：

    relabel_configs:
  - action: replace
    source_labels: ['instance']
    target_label: 'new_instance'
    regex: '(.+):\\d+'
    replacement: '$1'

    在这个例子中，replace 操作使用正则表达式 (.+):\\d+ 匹配 instance 标签值中的 IP 地址和端口信息，然后使用 $1 保留 IP 地址部分，并将结果赋给新的 new_instance 标签。

labelmap 操作：

  • 作用： labelmap 操作用于生成新的标签映射，根据正则表达式匹配的标签名称的一部分生成新的标签。

  • 示例：

    relabel_configs:
  - action: labelmap
    regex: __meta_(.+)

    在这个例子中，labelmap 操作使用正则表达式 __meta_(.+) 匹配以 __meta_ 前缀的标签名称，然后使用捕获组 (.+) 生成新的标签，该标签以 __meta_ 为前缀。

区别：

  1. 操作目的：

    • replace 操作主要用于修改目标标签值。
    • labelmap 操作主要用于生成新的标签映射。

  2. 匹配方式：

    • replace 操作通过正则表达式匹配源标签值。
    • labelmap 操作通过正则表达式匹配标签名称。

  3. 生成标签：

    • replace 操作生成一个新的标签，将匹配的部分替换为指定的内容。
    • labelmap 操作生成一个新的标签，使用正则表达式中的捕获组生成新的标签值。

  4. 应用场景：

    • replace 操作通常用于调整目标标签的值，例如去除端口信息、重命名标签等。
    • labelmap 操作通常用于处理元信息标签，以提取关键信息生成新的标签。

总体而言，replace 操作用于更直接的标签值修改，而 labelmap 操作用于生成新的标签，一般用于更复杂的标签映射需求。选择使用哪种操作取决于具体的监控场景和需求。

之前的例子举例

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]
    relabel_configs:
    - source_labels:
      - "__address__"
      target_label: "address"
      regex: "(.*)"
      replacement: ${1}
      action: replace


scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]
    relabel_configs:
      - regex: "__(address)__"
        replacement: "ip_${1}"
        action: labelmap

两个 scrape_configs 的配置看起来存在一些混淆，因为其中的 job_name 和 static_configs 重复了。我将其整合成一个单一的配置，如下：

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]
    relabel_configs:
      - source_labels:
          - "__address__"
        target_label: "address"
        regex: "(.*)"
        replacement: "${1}"
        action: replace
      - regex: "__(address)__"
        replacement: "ip_${1}"
        action: labelmap

现在，让我解释这个整合后的配置：

  • job_name: "prometheus"： 指定了作业的名称为 “prometheus”，表示这个抓取任务属于 “prometheus” 作业。

  • static_configs： 这里使用了 static_configs，表示这是一个静态目标的配置，而不是通过服务发现动态发现目标。

  • targets: ["localhost:9090"]： 指定了具体的监控目标，这里是本地主机的 Prometheus 实例运行在端口 9090 上。

  • relabel_configs： 这是一个对目标标签进行处理的配置块，包含了两个 relabel 规则：

    1. 第一个 relabel 规则：

      • source_labels: ['__address__']： 指定了要修改的源标签为 __address__。
      • target_label: 'address'： 将修改后的值赋给新的标签 address。
      • regex: "(.*)"： 使用正则表达式 (.*) 匹配整个地址。
      • replacement: "${1}"： 使用正则表达式中的捕获组 ${1} 作为替换值。
      • action: replace： 表示执行 replace 操作，替换标签值。

    2. 第二个 relabel 规则：

      • regex: "__(address)__"： 使用正则表达式匹配标签名称，这里匹配的是 __(address)__。
      • replacement: "ip_${1}"： 当匹配成功时，将使用 “ip_” 前缀和匹配的内容 ${1} 替换标签的值。
      • action: labelmap： 表示执行 labelmap 操作，生成新的标签映射。

综合起来，这个配置的作用是将 __address__ 标签的值复制到新的标签 address 中，并将 __address__ 中的内容添加前缀 “ip_” 并生成新的标签映射。这有助于更好地组织和描述监控目标的地址信息。

labeldrop

删除匹配正则表达式的标签。

relabel_configs:
  - action: labeldrop
    regex: unwanted_label.*

labeldrop

  • 匹配regex所有标签名称，对匹配到的实例标签进行删除
  • 将regex对所有的标签名进行匹配判定，能够匹配到的标签将从该target的标签集中删除；

在 Prometheus 的 relabel_configs 中，labeldrop 操作用于删除匹配正则表达式的标签，从而减少或清理目标的标签集。以下是 labeldrop 操作的详细解释：

relabel_configs:
  - action: labeldrop
    regex: unwanted_label.*

  • 作用： labeldrop 操作的主要作用是根据正则表达式 regex 匹配的标签名称，删除这些标签，从而减少或清理目标的标签集。

  • 使用场景： labeldrop 操作通常用于去除不需要的或无关紧要的标签，以简化目标的标签集。这在清理和组织监控数据时非常有用。

  • 示例： 下面是一个示例，展示了如何使用 labeldrop 操作删除以 unwanted_label 开头的标签：

    relabel_configs:
  - action: labeldrop
    regex: unwanted_label.*

    在这个例子中，所有以 unwanted_label 开头的标签都将被删除，从而简化目标的标签集。

labeldrop 操作提供了一种简单而有效的方式，通过正则表达式匹配删除目标的标签，以满足清理或简化监控数据的需求。这对于确保目标标签集清晰、有序并符合组织规范非常有帮助。

hashmod

使用哈希模数对目标进行分片。

relabel_configs:
  - action: hashmod
    modulus: 2
    source_labels: ['instance']
    target_label: 'shard'

hashmod

  • 将target_label的值设置为一个hash值，该hash则由modules字段指定的hash模对块对source_labels 上各标签的串连值进行hash计算生成；

在 Prometheus 的 relabel_configs 中，hashmod 操作用于通过哈希模数的方式对目标进行分片。这可以用于在抓取时将目标分配到不同的处理实例，实现一种简单的分布式处理。以下是 hashmod 操作的详细解释：

relabel_configs:
  - action: hashmod
    modulus: 2
    source_labels: ['instance']
    target_label: 'shard'

  • 作用： hashmod 操作的主要作用是根据 source_labels 定义的源标签值，使用哈希模数算法计算哈希值，然后将哈希值除以 modulus 得到的余数作为新的标签值，并将结果赋给 target_label 定义的目标标签。这通常用于将目标分散到多个处理实例中，实现简单的负载均衡。

  • 使用场景： hashmod 操作通常用于处理抓取目标的负载均衡，确保不同的目标被均匀地分配到不同的处理实例上。

  • 示例： 下面是一个示例，展示了如何使用 hashmod 操作将目标按照 instance 标签的哈希值分配到两个处理实例：

    relabel_configs:
  - action: hashmod
    modulus: 2
    source_labels: ['instance']
    target_label: 'shard'

    在这个例子中，instance 标签的值经过哈希模数运算，结果余数为 0 或 1，分别被赋给 shard 标签，实现了两个处理实例之间的均衡分配。

hashmod 操作允许在配置中基于哈希值对目标进行分片，这对于实现简单的负载均衡非常有用。这种操作使得 Prometheus 能够将监控目标在多个处理实例上均匀分布，以提高整体性能。

labelkeep

保留匹配正则表达式的标签，删除其他标签。

relabel_configs:
  - action: labelkeep
    regex: allowed_label.*

labelkeep

  • 匹配regex所有标签名称，对匹配到的实例标签进行保留
  • 将regex对所有的标签名进行匹配判定，不能匹配到的标签将从该target的标签集中删除；

**注意：**要确保在labeldrop或labelkeep操作后，余下的标签集依然能惟一标识该指标

在 Prometheus 的 relabel_configs 中，labelkeep 操作用于保留匹配正则表达式的标签，而删除其他标签，从而对目标的标签进行精简。以下是 labelkeep 操作的详细解释：

relabel_configs:
  - action: labelkeep
    regex: allowed_label.*

  • 作用： labelkeep 操作的主要作用是保留匹配正则表达式 regex 的标签，删除其他标签。这通常用于筛选和保留特定的标签，以确保目标的标签集合清晰和有序。

  • 使用场景： labelkeep 操作通常用于精简目标的标签集，去除不需要的标签，只保留关键的或感兴趣的标签，以便在查询和分析时更轻松地处理数据。

  • 示例： 下面是一个示例，展示了如何使用 labelkeep 操作保留以 allowed_label 开头的标签，并删除其他标签：

    relabel_configs:
  - action: labelkeep
    regex: allowed_label.*

    在这个例子中，所有以 allowed_label 开头的标签将被保留，而其他标签将被删除，以简化目标的标签集。

labelkeep 操作为在配置中选择性地保留目标的标签提供了一种便捷的方式。通过匹配正则表达式，你可以定制化地选择要保留的标签，以便更好地组织和处理监控数据。

标签重命名

你可以使用 relabel 将目标标签的名称更改为其他名称，这有助于使标签更具描述性、易读或符合组织规范。例如，你可以将 instance 标签改为 hostname 标签。

relabel_configs:
  - source_labels: ['instance']
    target_label: 'hostname'

标签值修改

你可以使用 relabel 修改目标标签的值，例如通过正则表达式替换、截取或添加前缀/后缀等方式。这使得你能够灵活地调整标签值以满足监控的需求。

修改 __address__ 标签，将其值中的端口信息去掉，然后将修改后的值赋给新的标签 instance。

relabel_configs:
  - source_labels: ['__address__']
    target_label: 'instance'
    regex: '(.+):\\d+'
    replacement: '$1'

  • source_labels: ['__address__']: 这里定义了源标签，即待修改的标签。在这个例子中，源标签是 __address__，它通常包含了监控目标的 IP 地址和端口信息。

  • target_label: 'instance': 这里定义了目标标签，即修改后的标签的名称。在这个例子中，目标标签是 instance，这意味着我们将修改后的值赋给 instance 标签。

  • regex: '(.+):\\d+': 这是一个正则表达式，用于匹配源标签的值。这个正则表达式的含义是匹配任意字符（(.+)），后面紧跟着冒号和一个或多个数字（:\\d+）。这样，整个正则表达式匹配了 IP 地址和端口组成的字符串。

  • replacement: '$1': 这是替换字段，指定了用于替换源标签值的字符串。在这个例子中，$1 表示取正则表达式中第一个括号捕获的内容，即 IP 地址部分。因此，最终目标标签的值将是去掉端口信息后的 IP 地址。

综合起来，这段 relabel_configs 的配置的效果是，将 __address__ 标签中的端口信息去掉，然后将修改后的值赋给 instance 标签。这样，你可以通过 instance 标签更清晰地识别和区分监控目标，而不受端口信息的影响。

多规则组合

你可以定义多个 relabel 规则，并且它们按照配置顺序逐一应用。这使得你能够组合多个规则以达到更复杂的目标标签操作效果。

relabel_configs:
  - source_labels: ['instance']
    target_label: 'hostname'
  - source_labels: ['__address__']
    target_label: 'instance'
    regex: '(.+):\\d+'
    replacement: '$1'

1

在 Prometheus 中，relabel_configs 提供了多个可选的阶段（phases），它们用于指定 relabel 配置的应用阶段。每个阶段定义了 relabel 规则应该在整个抓取配置处理的过程中的哪个时期执行。以下是 relabel_configs 可用的阶段：

  1. replace 阶段： 这是默认阶段，relabel 规则在 replace 阶段被执行。在这个阶段，会应用标签替换、添加或删除等操作。

    relabel_configs:
  - source_labels: ['__address__']
    target_label: 'instance'
    regex: '(.+):\\d+'
    replacement: '$1'

  2. meta 阶段： 如果指定 source_labels，则在 meta 阶段执行 relabel 规则。该阶段不会应用标签替换，而是用于在目标上设置元数据标签。

    relabel_configs:
  - source_labels: ['__address__']
    target_label: '__meta_instance'

  3. labelmap 阶段： 该阶段用于将标签映射到新的标签。这在需要动态生成标签名称时非常有用。

    relabel_configs:
  - action: labelmap
    regex: __meta_(.+)

  4. labeldrop 阶段： 在 labeldrop 阶段执行的规则用于删除匹配给定正则表达式的标签。

    relabel_configs:
  - action: labeldrop
    regex: unwanted_label.*

  5. prerelabel 和 postrelabel 阶段： 这两个阶段用于在 replace 阶段之前或之后执行 relabel 规则。prerebel 规则在目标刷新之前执行，而 postrelabel 规则在目标刷新之后执行。

    relabel_configs:
  - action: replace
    source_labels: ['__address__']
    target_label: 'instance'
    regex: '(.+):\\d+'
    replacement: '$1'
    on: prerelabel

这些阶段提供了灵活性，允许你在整个目标刷新和标签处理过程中的不同阶段应用 relabel 规则。根据具体的需求和场景，你可以选择在合适的阶段执行相应的标签操作。

metric_relabel_configs

  • metric_relabel_configs 可以实现对抓取到的metric重新打标
  • 对metric重新打标是在数据抓取之后动态重写metric标签的工具，在每个数据抓取配置中，可以定义多个metric relabel的步骤，它们将按照定义的顺序依次执行；
  • 对metric重新打标的配置格式与target重新打标的格式相同，但前者要定义在专用的 metric_relabel_configs字段中；

应用场景：

  • 删除不必要的指标（最常用）；
  • 从指标中删除敏感或不需要的标签；
  • 添加、编辑或修改指标的标签值或标签格式；

注意事项：

  • 更改或添加标签会创建新的时间序列，因此应该明确地使用各个标签，并尽可能保持不变，以避免创建出一个动态的数据环境；
  • 标签是时间序列的唯一性约束，如果因为删除标签而导致时间序列重复时，可能会导致系统出现问题，因此非必要不要删除标签

1

metric_relabel_configs 除了和 scrape_configs 名称不一样外，其他的配置和scrape_configs都一样对吗？

metric_relabel_configs 是 Prometheus 配置文件中用于对采集到的指标进行修改的部分，它与 scrape_configs 有相似的配置结构，但是用于对抓取到的指标进行处理而不是对目标标签进行处理。下面是对比它们的主要区别：

scrape_configs（用于目标配置）：

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]
    relabel_configs:
      - source_labels:
          - "__address__"
        target_label: "address"
        regex: "(.*)"
        replacement: "${1}"
        action: replace
      - regex: "__(address)__"
        replacement: "ip_${1}"
        action: labelmap

metric_relabel_configs（用于指标配置）：

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]
    metric_relabel_configs:
      - source_labels: ['example_label']
        target_label: 'new_label'
        regex: '(.*)'
        replacement: '$1'
        action: replace
      - regex: '(.+)'
        replacement: 'prefix_$1'
        action: labelmap

主要区别：

  1. 名称不同： 一个用于配置抓取目标的 relabel_configs，而另一个用于配置指标的 metric_relabel_configs。

  2. 操作对象： relabel_configs 用于目标标签的处理，而 metric_relabel_configs 用于采集到的指标值的处理。

  3. 具体应用： relabel_configs 用于调整目标标签的值，例如替换、删除、映射等。metric_relabel_configs 用于调整抓取到的指标值，例如替换、添加前缀等。

  4. 示例区别： 在上述示例中，metric_relabel_configs 的第一个规则将 example_label 的值复制到新的标签 new_label 中，并将值本身添加前缀。第二个规则是一个 labelmap 操作，将匹配的内容添加前缀。

总体而言，它们的配置结构类似，但用途不同，分别用于处理目标标签和采集到的指标值。

metric_relabel Example - 删除指标

实现前

init_metric

drop

  • prometheus 默认会将所有拉取到的 metrics 都写入自己的存储中。如果某些 metrics 对我们并没有太多意义，可以设置直接丢掉，减少磁盘空间的浪费。

  • 下面的示例，用于在相应的job上，在发现的各target之上，删除以“go_info”为前 名称前缀的指标

实现

  • prometheus.yml
...
scrape_configs:
# Prometheus
  - job_name: "prometheus"
    file_sd_configs:
    - files:
      - targets/prometheus/prometheus*.yaml

# Node
  - job_name: "node-exporter"
    file_sd_configs:
    - files:
      - targets/prometheus/node-exporter*.yaml

    metric_relabel_configs:
    - source_labels:
      - "__name__" # __name__ 标签是标识指标名称的预留标签，表示选择指标名称
      regex: "go_info" # 选择go_info的指标名称，支持以通配符的形式选择多个名称，例如：node_cpu_.*
      action: drop # 删除

# Alertmanager
  - job_name: 'alertmanager'
    file_sd_configs:
    - files:
      - targets/prometheus/alertmanager*.yaml

验证

  • 若删除的指标此前曾由Prometheus抓取并存储过相关的样本数据，则删除操作的 需要经过一定的时长后才会反映至查询结果中；
metric_relabel-drop

relabel Example - 替换指标名

注意事项

非必要，不要删除target的标签

在Prometheus中，不建议非必要地删除target的标签，这是因为标签在Prometheus中扮演着重要的角色，对于监控系统的性能和可用性有着关键的影响。以下是一些原因：

  1. 标签用于唯一标识目标（target）： 标签是用来唯一标识监控目标的关键信息。删除标签可能导致丢失目标的唯一性，使得Prometheus无法准确识别和区分不同的目标。这可能导致数据混淆、聚合错误或者难以进行有意义的查询。

  2. 标签用于标识监控数据的上下文： 标签可以为监控数据提供上下文信息，帮助用户更好地理解和分析数据。如果删除了标签，可能会丢失对数据的关键上下文，降低数据的可读性和可理解性。

  3. Prometheus的查询和聚合依赖于标签： Prometheus的查询和聚合功能是基于标签来实现的。删除标签可能导致查询和聚合操作的不准确性，因为Prometheus无法正确地根据标签对数据进行过滤和分组。

  4. 标签用于目标发现和动态配置： Prometheus支持目标发现和动态配置，其中标签是用来过滤和匹配目标的重要元素。删除标签可能会导致配置不一致，影响到Prometheus的目标发现和监控功能。

总的来说，保留目标的标签是确保Prometheus正常运行和正确监控的重要一环。当然，在一些特殊情况下，可能需要删除标签，但在这种情况下，应该仔细考虑潜在的影响，并确保删除操作是经过慎重评估和测试的。

示例：relabel

  - source_labels: [__address__]
    separator: ;
    regex: (.*)
    target_label: __param_target
    replacement: $1
    action: replace
  - separator: ;
    regex: (.*)
    target_label: __address__
    replacement: blackbox
    action: replace

—