Prometheus 0.14.0 中的高级服务发现
2015年6月1日作者 Fabian Reinartz, Julius Volz
本周我们发布了 Prometheus v0.14.0——这是一个包含许多期待已久的增强功能和改进的版本。
在用户侧，Prometheus 现在支持新的服务发现机制。除了 DNS-SRV 记录外，它现在还开箱即用地支持 Consul ，并且一个基于文件的接口允许您连接自己的发现机制。随着时间的推移，我们计划在 Prometheus 中添加其他常见的服务发现机制。
除了许多小的修复和改进之外，现在您还可以通过向 Prometheus 进程发送 SIGHUP 信号，在运行时重载配置。如需完整的更改列表，请查看 此版本的更新日志 。
在这篇博文中，我们将深入了解内置的服务发现机制并提供一些实际示例。作为额外资源，请参阅 Prometheus 的配置文档。
Prometheus 与目标（Targets）
为了更好地理解这篇博文，我们首先需要了解 Prometheus 如何标记目标。
配置文件中有多个地方可以设置目标标签。它们按以下顺序应用，后续阶段会覆盖之前阶段设置的任何标签：
- 全局标签：分配给 Prometheus 实例抓取的每一个目标。
job标签：配置为每个抓取配置的默认值。- 在每个抓取配置内的目标组级别设置的标签。
- 通过 重标记（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 名称。如果我们有类似 telemetry.<zone>.<job>.srv.example.org 这样结构化的 SRV 记录名称，我们可以从中提取相关的标签：
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 格式。对于较小的配置，我们建议手动升级以熟悉新格式并保留注释。