汇总：Prometheus监控神器-服务发现篇（二）

　　Prometheus监控工件服务发现（二）

　　本章介绍了服务发现和重新标记的机制和示例。

　　通过服务发现，我们可以动态发现需要监视的目标实例信息，而无需重新启动Prometheus服务。

　　

　　如上图所示，对于在线环境，我们可以分为不同的集群：dev，stage和prod。每个群集运行多个主机节点，每个服务器节点运行一个节点导出器实例。 Node Exporter实例会自动在Consul中注册，Prometheus会根据Consul返回的Node Exporter实例信息动态维护Target列表，并轮询这些目标以监视数据。

　　但是，如果我们仍然需要：

　　面对这些情况下的要求，我们实际上希望Prometheus Server可以根据某些规则（例如，标记）监视数据从服务发现注册表返回的目标实例中选择性地采集某些Exporter实例。

　　接下来，我们将尝试如何通过Prometheus强大的Relabel机制实现这些特定目标。

　　普罗米修斯的重新标记机制

　　Prometheus的所有Target实例都收录一些默认的元数据标记信息。您可以在Prometheus UI的“目标”页面中查看这些实例的元数据标签的内容：

　　

　　默认情况下，当Prometheus加载Target实例时，这些Target将收录一些默认标记：

　　以上标记将告诉Prometheus如何从Target实例获取监视数据。除了这些默认标签之外，我们还可以为目标添加自定义标签。例如，在“基于文件的服务发现”部分的示例中，我们通过JSON配置文件将自定义标签env添加到Target实例。如下所示，标签最终将保存在此实例采集的示例数据中：

　　node_cpu{cpu="cpu0",env="prod",instance="localhost:9100",job="node",mode="idle"}

　　通常，系统内部使用以__作为Target前面的标签，因此不会将这些标签写入示例数据。但是，也有一些例外。例如，我们将发现通过Prometheus 采集传递的所有样本数据都将收录一个名为instance的标签，其内容对应于Target实例的__address__。这实际上是一个标签重写过程。

　　这种重写目标实例标签的机制是在采集样本数据在Prometheus中称为“重新标记”之前发生的。

　　

　　Prometheus允许用户通过采集任务设置中的relabel_configs添加自定义的重新标记过程。

　　使用replace / labelmap重写标签

　　重新标记的最基本的应用场景是基于Target实例中收录的元数据标签动态添加或覆盖标签。例如，通过Consul动态发现的服务实例还将收录以下元数据标签信息：

　　默认情况下，来自Node Exporter实例采集的示例数据如下：

　　node_cpu{cpu="cpu0",instance="localhost:9100",job="node",mode="idle"} 93970.8203125

　　我们希望有一个附加标签dc，它可以指示样本所属的数据中心：

　　node_cpu{cpu="cpu0",instance="localhost:9100",job="node",mode="idle", dc="dc1"} 93970.8203125

　　可以将多个relabel_config配置添加到每个采集任务的配置中。最简单的重新标记配置如下：

　　scrape_configs:

- job_name: node_exporter

consul_sd_configs:

- server: localhost:8500

services:

- node_exporter

relabel_configs:

- source_labels: ["__meta_consul_dc"]

target_label: "dc"

　　此采集任务通过Consul作为采集的监视目标来动态发现Node Exporter实例信息。在上一节中，我们知道通过Consul动态发现的监视目标将收录一些其他元数据标签，例如__meta_consul_dc标签，指示当前实例所在的Consul数据中心，因此我们希望从这些实例进行监视采集该示例还可以收录这样的标签，例如：

　　node_cpu{cpu="cpu0",dc="dc1",instance="172.21.0.6:9100",job="consul_sd",mode="guest"}

　　通过这种方式，可以方便地根据dc标签的值对不同数据中心的数据进行汇总和分析。

　　在此示例中，通过从Target实例获取__meta_consul_dc的值，并重写从该实例获得的所有样本。

　　完整的relabel_config配置如下：

　　# The source labels select values from existing labels. Their content is concatenated

# using the configured separator and matched against the configured regular expression

# for the replace, keep, and drop actions.

[ source_labels: '[' [, ...] ']' ]

# Separator placed between concatenated source label values.

[ separator: | default = ; ]

# Label to which the resulting value is written in a replace action.

# It is mandatory for replace actions. Regex capture groups are available.

[ target_label: ]

# Regular expression against which the extracted value is matched.

[ regex: | default = (.*) ]

# Modulus to take of the hash of the source label values.

[ modulus: ]

# Replacement value against which a regex replace is performed if the

# regular expression matches. Regex capture groups are available.

[ replacement: | default = $1 ]

# Action to perform based on regex matching.

[ action: | default = replace ]

　　动作定义了元数据标签的当前relabel_config处理方法，默认动作行为是replace。替换行为将根据regex配置匹配source_labels标签的值（多个source_label的值将根据分隔符进行拼接），并将匹配的值写入target_label。如果有多个匹配组，则可以使用$ {1}，$ {2}确定要写入的内容。如果没有匹配项，则不会重置target_label。

　　通过repalce操作，用户可以根据Target的Metadata标签重写或编写新的标签键值对。在多环境的情况下，它可以帮助用户添加与环境相关的特征尺寸，从而更好地执行数据聚合。

　　除了使用replace之外，还可以将操作配置定义为labelmap。与replace不同，labelmap将根据正则表达式的定义匹配Target实例的所有标签的名称，并使用匹配的内容作为新标签名称，并将其值用作新标签的值。

　　例如，当监视Kubernetes下的所有主机节点时，要将在这些节点上定义的标签写到样本中，可以使用以下relabel_config配置：

　　- job_name: 'kubernetes-nodes'

kubernetes_sd_configs:

- role: node

relabel_configs:

- action: labelmap

regex: __meta_kubernetes_node_label_(.+)

　　使用labelkeep或labeldrop过滤目标标签，并仅保留符合过滤条件的标签，例如：

　　relabel_configs:

- regex: label_should_drop_(.+)

action: labeldrop

　　此配置将使用正则表达式来匹配当前Target实例的所有标签，并从Target实例中删除符合regex规则的标签。 labelkeep相反，它将删除所有不匹配正则表达式定义的标签。

　　使用保留/删除过滤目标实例

　　在上一部分中，我们介绍了Prometheus的重新标记机制，并使用replace / labelmap / labelkeep / labeldrop来管理标签。在本节的开头提到了第二个问题。使用集中式服务发现注册表时，环境中的所有导出器实例都将在服务发现注册表中注册。具有不同功能（开发，测试，操作和维护）的人员可能只关心某些监视数据。他们可以部署自己的Prometheus Server来监视他们关心的指标数据。如果将这些Prometheus Server 采集放在所有环境中，显然，所有Exporter数据都将浪费大量资源。如何使这些不同的Prometheus Server 采集各自引起关注？答案是重新标记。除默认替换外，relabel_config的操作还支持保留/删除行为。例如，如果只需要采集数据中心dc1中的Node Exporter实例的样本数据，则可以使用以下配置：

　　scrape_configs:

- job_name: node_exporter

consul_sd_configs:

- server: localhost:8500

services:

- node_exporter

relabel_configs:

- source_labels: ["__meta_consul_dc"]

regex: "dc1"

action: keep

　　将动作设置为保持时，Prometheus将丢弃与source_labels的值中的正则表达式正则表达式的内容不匹配的Target实例，并且在将动作设置为drop时，它将丢弃与正则表达式正则表达式。内容的Target实例。可以简单地理解为保留以供选择，丢弃以排除。

　　使用hashmod计算source_labels的哈希值

　　当relabel_config设置为hashmod时，Prometheus将使用模量值作为系数来计算source_labels值的哈希值。例如：

　　scrape_configs

- job_name: 'file_ds'

relabel_configs:

- source_labels: [__address__]

modulus: 4

target_label: tmp_hash

action: hashmod

file_sd_configs:

- files:

- targets.json

　　根据当前Target实例__address__的值，使用4作为系数，以便每个Target实例将收录一个新标签tmp_hash，其值范围在1〜4之间。查看目标实例的标签信息。看到以下结果，每个Target实例都收录一个新的tmp_hash值：

　　使用Hashmod的功能在目标实例级别实现采集任务的功能分区：

　　scrape_configs:

- job_name: some_job

relabel_configs:

- source_labels: [__address__]

modulus: 4

target_label: __tmp_hash

action: hashmod

- source_labels: [__tmp_hash]

regex: ^1$

action: keep

　　此处应注意，如果重新标记操作仅是为了生成临时变量作为下一个重新标记操作的输入，则可以使用__tmp作为标签名称的前缀，并且该前缀定义的标签将不写到目标的标签或样本的采集。