本周我们发布了 Prometheus v0.14.0——一个包含许多期待已久的添加和改进的版本。
在用户端，Prometheus 现在支持新的服务发现机制。除了 DNS-SRV 记录外，它现在开箱即用地支持 Consul，并且一个基于文件的接口允许您连接自己的发现机制。随着时间的推移，我们计划向 Prometheus 添加其他常见的服务发现机制。
除了许多小的修复和改进之外，您现在还可以通过向 Prometheus 进程发送 SIGHUP 信号在运行时重新加载配置。有关更改的完整列表，请查看此版本的更新日志。
在这篇博客文章中，我们将仔细研究内置的服务发现机制并提供一些实际示例。作为附加资源，请参阅Prometheus 的配置文档。
Prometheus 与目标
为了正确理解这篇博客文章，我们首先需要了解 Prometheus 如何标记目标。
配置文件中有多个地方可以设置目标标签。它们按以下顺序应用，后面的阶段会覆盖前面阶段设置的任何标签：
- 全局标签，分配给 Prometheus 实例抓取的每个目标。
job标签，配置为每个抓取配置的默认值。- 在抓取配置中按目标组设置的标签。
- 通过重新标记进行高级标签操作。
每个阶段都会覆盖前一阶段的任何冲突标签。最终，我们得到一组描述单个目标的扁平化标签。这些标签会附加到从该目标抓取的每个时间序列中。
注意：在内部，即使目标的地址也存储在一个特殊的 __address__ 标签中。这在进行高级标签操作（重新标记）时非常有用，我们稍后会看到。以 __ 开头的标签不会出现在最终的时间序列中。
抓取配置与重新标记
除了从 ASCII protocol buffer 格式改为 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'
通过名为重新标记的机制，可以对每个目标级别的任何标签进行删除、创建或修改。这实现了细粒度的标签设置，还可以考虑来自服务发现的元数据。重新标记是标签分配的最后一个阶段，它会覆盖之前设置的任何标签。
重新标记的工作方式如下：
- 定义一个源标签列表。
- 对于每个目标，将这些标签的值用分隔符连接起来。
- 使用正则表达式匹配结果字符串。
- 根据这些匹配结果，将一个新值分配给另一个标签。
每个抓取配置可以定义多个重新标记规则。一个简单的将两个标签合并为一个的规则如下所示：
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 辅助程序（side-kick）运行的小型桥接程序。它从任意服务发现机制中获取更改，并将目标信息写入被监控的文件中，作为目标组列表。
这些文件可以是 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 格式。对于较小的配置，我们建议手动升级，以便熟悉新格式并保留注释。