本期作者:罗韦
爱可生上海研发中心成员,研发工程师,主要负责 DMP 平台监控告警功能的相关工作。
上篇文章(第02期:数据采集一)介绍了 Prometheus 数据采集的格式和分类,本文会对采集过程进行详细的介绍。
target:采集目标,Prometheus Server 会从这些目标设备上采集监控数据
sample: Prometheus Server 从 targets 采集回来的数据样本
meta label: 执行 relabel 前,target 的原始标签。可在 Prometheus 的 /targets
页面或发送 GET /api/v1/targets
请求查看。
relabel 是 Prometheus 提供的一个针对 target 的功能,relabel 发生 Prometheus Server 从 target 采集数据之前,可以对 target 的标签进行修改或者使用标签进行 target 筛选。注意以下几点:
在 Prometheus 的 targets 页面,可以看到 target 在 relabel 之前的标签,如下图所示,在 relabel 之前,target 的标签有:"__address__","__metrics_path__","__schema__","job"。经过 relabel 之后我们最终看到的 targets 的标签为:instance、job。
relabel 的基本配置项:
下面举几个使用 relabel 配置的例子:
scrape_configs:
- job_name: prometheus
relabel_configs:
- source_labels: ["__address__"] #我们要替换的 meta label 为"__address__"
target_label: "host" #给 targets 新增一个名为 "host" 的标签
regex: "(.*):(.*)" #将匹配的内容分为两部分 groups--> (host):(port)
replacement: $1 #将匹配的 host 第一个内容设置为新标签的值
action: replace
运行结果:
relabel_configs:
- source_labels: ["__metrics_path__"] #我们要替换的 meta label 为 "__metrics_path__"
target_label: "metrics_path" #给 targets 新增一个名为 "metrics_path" 的标签
- source_labels: ["host"]
regex: "localhost" #只保留 host 标签值为 "localhost" 的 targets
action: keep
运行结果:
在 targets 页面只剩下一个 target
Prometheus 通过 http 从 target 采集所有 metrics 的样本,http 路径可以通过下的 "metrics_path" 配置,默认为 "/metrics"。请求超时时间配置在下的 "scrape_timeout",默认 10s,可根据网络状况作相应调整。标签的合法性也会在这个过程中检查。
Prometheus 会默认给 metric 添加一些标签,如 "job"、"instance",或者某些配置项配置了一些特定标签,如果采集回来的时间序列也存在同名的标签,那冲突就产生了。下的 "honor_labels" 就是用来解决这样的场景的,如果 "honor_labels" 设置为 "true",那么冲突标签的值会使用采集到的标签值;如果设置为 "false",采集上来的冲突标签会被重命名:加上 "exported_" 前缀,如 "exported_job"、"exported_instance" 。
metric_relabel 功能、配置和 relabel 类似,区别在于 metric_relabel 针对 sample 的标签,在 config 文件中的配置项为。metric_relabel 不支持 Prometheus 自动生成的时间序列,如"up"、"scrape_duration_seconds"、"scrape_samples_scraped"、"scrape_samples_post_metric_relabeling"、"scrape_series_added"等。通常用于过滤掉意义不大、或采集成本过高的时间序列。
经过一系列处理后,采集到的数据会被持久化保存,关于数据存储会在后续文章中介绍。