Prometheus 0.14.0 中的高级服务发现

本周我们发布了 Prometheus v0.14.0 —— 一个包含了许多期待已久的补充和改进的版本。

在用户方面，Prometheus 现在支持新的服务发现机制。除了 DNS-SRV 记录，它现在还原生支持 Consul，并且一个基于文件的接口允许您连接自己的发现机制。随着时间的推移，我们计划将其他常见的服务发现机制添加到 Prometheus 中。

除了许多较小的修复和改进之外，您现在还可以通过向 Prometheus 进程发送 SIGHUP 信号来在运行时重新加载配置。有关更改的完整列表，请查看此版本的 更新日志。

在本篇博文中，我们将仔细研究内置的服务发现机制，并提供一些实用示例。作为额外资源，请参阅 Prometheus 的配置文档。

Prometheus 与目标

为了正确理解本篇博文，我们首先需要了解 Prometheus 如何为目标添加标签。

配置文件中有多个地方可以设置目标标签。它们按以下顺序应用，后面的阶段会覆盖前面阶段设置的任何标签：

1. 全局标签，分配给 Prometheus 实例抓取的所有目标。
2. job 标签，为每个抓取配置配置的默认值。
3. 在抓取配置中按目标组设置的标签。
4. 通过重新标记 (relabeling) 进行高级标签操作。

每个阶段都会覆盖早期阶段中任何冲突的标签。最终，我们得到一组扁平的标签来描述单个目标。然后，这些标签会附加到从该目标抓取的每个时间序列上。

注意：在内部，即使目标的地址也存储在一个特殊的 __address__ 标签中。这在高级标签操作（重新标记）期间会很有用，我们稍后会看到。以 __ 开头的标签不会出现在最终的时间序列中。

抓取配置与重新标记

除了从 ASCII 协议缓冲区格式迁移到 YAML 之外，Prometheus 配置的一个根本性变化是从按作业配置变为更通用的抓取配置。虽然对于简单设置来说两者几乎等效，但抓取配置在更高级的用例中提供了更大的灵活性。

每个抓取配置定义一个作业名称，作为 job 标签的默认值。job 标签可以为整个目标组或单个目标重新定义。例如，我们可以定义两个目标组，每个组定义一个作业的目标。要使用相同的参数抓取它们，我们可以如下配置：

scrape_configs:
- job_name: 'overwritten-default'

  scrape_interval: 10s
  scrape_timeout:  5s

  target_groups:
  - targets: ['10.1.200.130:5051', '10.1.200.134:5051']
    labels:
      job: 'job1'

  - targets: ['10.1.200.130:6220', '10.1.200.134:6221']
    labels:
      job: 'job2'

通过一种名为重新标记 (relabeling) 的机制，可以在每个目标级别上移除、创建或修改任何标签。这实现了细粒度的标签设置，还可以考虑来自服务发现的元数据。重新标记是标签分配的最后阶段，并会覆盖之前设置的任何标签。

重新标记的工作方式如下：

• 定义源标签列表。
• 对于每个目标，这些标签的值会用分隔符连接起来。
• 将正则表达式与结果字符串进行匹配。
• 根据这些匹配，将新值分配给另一个标签。

可以为每个抓取配置定义多个重新标记规则。一个将两个标签合并为一个的简单规则如下所示：

relabel_configs:
- source_labels: ['label_a', 'label_b']
  separator:     ';'
  regex:         '(.*);(.*)'
  replacement:   '${1}-${2}'
  target_label:  'label_c'

此规则将具有以下标签集的目标转换为

{
  "job": "job1",
  "label_a": "foo",
  "label_b": "bar"
}

...具有以下标签集的目标：

{
  "job": "job1",
  "label_a": "foo",
  "label_b": "bar",
  "label_c": "foo-bar"
}

然后您还可以在额外的重新标记步骤中删除源标签。

您可以在配置文档中阅读更多关于重新标记以及如何使用它来过滤目标的信息。

在接下来的部分中，我们将看到在使用服务发现时如何利用重新标记。

使用 DNS-SRV 记录进行发现

从一开始，Prometheus 就支持通过 DNS-SRV 记录进行目标发现。相应的配置如下所示：

job {
  name: "api-server"
  sd_name: "telemetry.eu-west.api.srv.example.org"
  metrics_path: "/metrics"
}

Prometheus 0.14.0 允许您在单个抓取配置中指定要查询的多个 SRV 记录，并提供服务发现特有的元信息，这在重新标记阶段非常有用。

当查询 DNS-SRV 记录时，一个名为 __meta_dns_name 的标签会附加到每个目标上。其值设置为返回该目标所用的 SRV 记录名称。如果我们的 SRV 记录名称是结构化的，例如 telemetry.<zone>.<job>.srv.example.org，我们可以从中提取相关的标签：

scrape_configs:
- job_name: 'myjob'

  dns_sd_configs:
  - names:
    - 'telemetry.eu-west.api.srv.example.org'
    - 'telemetry.us-west.api.srv.example.org'
    - 'telemetry.eu-west.auth.srv.example.org'
    - 'telemetry.us-east.auth.srv.example.org'

  relabel_configs:
  - source_labels: ['__meta_dns_name']
    regex:         'telemetry\.(.+?)\..+?\.srv\.example\.org'
    target_label:  'zone'
    replacement:   '$1'
  - source_labels: ['__meta_dns_name']
    regex:         'telemetry\..+?\.(.+?)\.srv\.example\.org'
    target_label:  'job'
    replacement:   '$1'

这将根据目标来源的 SRV 记录，为每个目标附加 zone 和 job 标签。

使用 Consul 进行发现

现在原生支持通过 Consul 进行服务发现。可以通过定义 Consul 代理的访问参数以及要查询目标的 Consul 服务列表来配置它。

每个 Consul 节点的标签通过可配置的分隔符连接起来，并通过 __meta_consul_tags 标签暴露。还提供了其他各种 Consul 特有的元标签。

使用简单的 consul_sd_config 和重新标记规则，可以实现抓取给定服务列表的所有实例：

scrape_configs:
- job_name: 'overwritten-default'

  consul_sd_configs:
  - server:   '127.0.0.1:5361'
    services: ['auth', 'api', 'load-balancer', 'postgres']

  relabel_configs:
  - source_labels: ['__meta_consul_service']
    regex:         '(.*)'
    target_label:  'job'
    replacement:   '$1'
  - source_labels: ['__meta_consul_node']
    regex:         '(.*)'
    target_label:  'instance'
    replacement:   '$1'
  - source_labels: ['__meta_consul_tags']
    regex:         ',(production|canary),'
    target_label:  'group'
    replacement:   '$1'

这会从本地 Consul 代理发现给定的服务。结果是，我们获得了四个作业（auth、api、load-balancer 和 postgres）的指标。如果节点具有 production 或 canary 的 Consul 标签，则会为目标分配相应的 group 标签。每个目标的 instance 标签设置为 Consul 提供的节点名称。

有关通过 Consul 进行服务发现的所有配置参数的完整文档，请参见 Prometheus 网站。

自定义服务发现

最后，我们添加了一个基于文件的接口，用于集成您的自定义服务发现或其他尚未原生支持的常见机制。

通过这种机制，Prometheus 会监视一组定义目标组的目录或文件。每当这些文件中的任何一个发生更改时，就会从文件中读取目标组列表，并提取抓取目标。现在我们的任务是编写一个小型桥接程序，作为 Prometheus 的辅助进程运行。它从任意服务发现机制中检索更改，并将目标信息作为目标组列表写入被监视的文件中。

这些文件可以是 YAML 格式的：

- targets: ['10.11.150.1:7870', '10.11.150.4:7870']
  labels:
    job: 'mysql'

- targets: ['10.11.122.11:6001', '10.11.122.15:6002']
  labels:
    job: 'postgres'

...或 JSON 格式的：

[
  {
    "targets": ["10.11.150.1:7870", "10.11.150.4:7870"],
    "labels": {
      "job": "mysql"
    }
  },
  {
    "targets": ["10.11.122.11:6001", "10.11.122.15:6002"],
    "labels": {
      "job": "postgres"
    }
  }
]

我们现在配置 Prometheus 来监视其工作目录中 tgroups/ 目录下的所有 .json 文件：

scrape_configs:
- job_name: 'overwritten-default'

  file_sd_configs:
  - names: ['tgroups/*.json']

现在缺少的是一个向此目录写入文件的程序。为了本示例，我们假设我们将不同作业的所有实例都保存在一个非规范化的 MySQL 表中。（提示：您可能不希望以这种方式进行服务发现。）

每 30 秒，我们从 MySQL 表中读取所有实例，并将生成的目标组写入 JSON 文件。请注意，我们无需维护任何目标或其标签是否已更改的状态。Prometheus 将自动检测更改并将其应用于目标，而不会中断它们的抓取周期。

import os, time, json

from itertools import groupby
from MySQLdb import connect


def refresh(cur):
    # Fetch all rows.
    cur.execute("SELECT address, job, zone FROM instances")

    tgs = []
    # Group all instances by their job and zone values.
    for key, vals in groupby(cur.fetchall(), key=lambda r: (r[1], r[2])):
        tgs.append({
            'labels': dict(zip(['job', 'zone'], key)),
            'targets': [t[0] for t in vals],
        })

    # Persist the target groups to disk as JSON file.
    with open('tgroups/target_groups.json.new', 'w') as f:
        json.dump(tgs, f)
        f.flush()
        os.fsync(f.fileno())

    os.rename('tgroups/target_groups.json.new', 'tgroups/target_groups.json')


if __name__ == '__main__':
    while True:
        with connect('localhost', 'root', '', 'test') as cur:
            refresh(cur)
        time.sleep(30)

虽然 Prometheus 不会将任何格式错误更改应用于文件，但最佳实践是通过重命名原子地更新文件，就像我们在示例中那样。还建议根据逻辑分组将大量目标组拆分为多个文件。

结论

借助 DNS-SRV 记录和 Consul，Prometheus 现在原生支持两种主要的服务发现方法。我们已经看到，重新标记是一种强大的方法，可以利用服务发现机制提供的元数据。

请务必查阅新的配置文档，以将您的 Prometheus 设置升级到新版本，并了解其他配置选项，例如基本 HTTP 认证和通过重新标记进行目标过滤。

我们提供一个迁移工具，可以将您现有的配置文件升级到新的 YAML 格式。对于较小的配置，我们建议手动升级，以便熟悉新格式并保留注释。