本期作者：罗韦 爱可生上海研发中心成员，研发工程师，主要负责 DMP 平台监控告警功能的相关工作。
上篇文章（第02期：数据采集一）介绍了 Prometheus 数据采集的格式和分类，本文会对采集过程进行详细的介绍。
Prometheus 数据采集过程介绍
Prometheus 从采集数据到将存储的过程中，会对采集目标及数据样本作一系列处理。了解这个过程有利于帮助我们更充分、合理的使用可配参数。
一、文章中使用的概念简介
**target：**采集目标，Prometheus Server 会从这些目标设备上采集监控数据 sample： Prometheus Server 从 targets 采集回来的数据样本 meta label： 执行 relabel 前，target 的原始标签。可在 Prometheus 的 /targets 页面或发送 GET /api/v1/targets 请求查看。
二、数据采集流程
2.1 relabel (targets 标签修改/过滤)
relabel 是 Prometheus 提供的一个针对 target 的功能，relabel 发生 Prometheus Server 从 target 采集数据之前，可以对 target 的标签进行修改或者使用标签进行 target 筛选。注意以下几点：
Prometheus 在 relabel 步骤默认会为 target 新增一个名为 instance 的标签，并设置成 "address" 标签的值； 在 relabel 结束后，以 "__" 开头的标签不会被存储到磁盘； meta label 会一直保留在内存中，直到 target 被移除。在 Prometheus 的 targets 页面，可以看到 target 在 relabel 之前的标签，如下图所示，在 relabel 之前，target 的标签有："address"，"metrics_path"，"schema"，"job"。经过 relabel 之后我们最终看到的 targets 的标签为：instance、job。
2.2 relabel 配置
relabel 的基本配置项：
source_labels: [<labelname>, ...] #需要进行 relabel 操作的 meta labels target_label: <labelname> #relabel 操作的目标标签，当使用 action 为 "replace" 时会把替换的结果写入 target_label regex: <regex> #正则表达式，用于在 source_labels 的标签值中提取匹配的内容。默认为"(.*)" modulus: <uint64> #用于获取源标签值的哈希的模数 replacement: <string> #regex 可能匹配到多个内容，replacement 指定要使用哪一个匹配内容进行替换，默认为 "$1"，表示使用第一个匹配的内容 action: <relabel_action> #定义对 source_labels 进行何种操作，默认为 "replace"下面举几个使用 relabel 配置的例子：
2.2.1 replace 修改标签
例 1. 继续使用上一个部署了两个 Prometheus 的环境，假如我们希望给 targets 添加一个 "host" 标签，内容取 "address" 的 host 部分，可以添加如下 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
运行结果：
例 2. "metrics_path" 标签保存了 target 提供的 metrics 访问路径，默认情况下"metrics_path" 标签在 relabel 之后是会被移除的，但是我们又希望在查询 metrics 时能方便的看到这个采集端的 metrics 访问路径，那么可以使用 replace 将 "metrics_path" 标签替换成我们希望的标签，并保留 "metrics_path" 的值，配置可以简化如下：**
relabel_configs:
- source_labels: ["__metrics_path__"] #我们要替换的 meta label 为 "__metrics_path__"
target_label: "metrics_path" #给 targets 新增一个名为 "metrics_path" 的标签
2.2.2 keep/drop 筛选 targets
例 3. 当需要过滤 target 时，可以将 action 项定义为 keep 或 drop。接着上面的例子我们再继续添加如下配置：
- source_labels: ["host"]
regex: "localhost" #只保留 host 标签值为 "localhost" 的 targets
action: keep
运行结果：在 targets 页面只剩下一个 target
三、scrape 拉取样本
Prometheus 通过 http 从 target 采集所有 metrics 的样本，http 路径可以通过下的 "metrics_path" 配置，默认为 "/metrics"。请求超时时间配置在下的 "scrape_timeout"，默认 10s，可根据网络状况作相应调整。标签的合法性也会在这个过程中检查。
3.1 honor label 冲突检查
Prometheus 会默认给 metric 添加一些标签，如 "job"、"instance"，或者某些配置项配置了一些特定标签，如果采集回来的时间序列也存在同名的标签，那冲突就产生了。下的 "honor_labels" 就是用来解决这样的场景的，如果 "honor_labels" 设置为 "true"，那么冲突标签的值会使用采集到的标签值；如果设置为 "false"，采集上来的冲突标签会被重命名：加上 "exported_" 前缀，如 "exported_job"、"exported_instance" 。
3.2 metric relabel（metric 标签重写）
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"等。通常用于过滤掉意义不大、或采集成本过高的时间序列。
3.3 save
经过一系列处理后，采集到的数据会被持久化保存，关于数据存储会在后续文章中介绍。