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

本章节讲解服务发现与Relabelling的机制与范例。

通过服务发现的方式，我们可以在不重启Prometheus服务的情况下动态的发现需要监控的Target实例信息。

如上图所示，对于线上环境我们可能会划分为:dev, stage, prod不同的集群。每一个集群运行多个主机节点，每个服务器节点上运行一个Node Exporter实例。Node Exporter实例会自动注册到Consul中，而Prometheus则根据Consul返回的Node Exporter实例信息动态的维护Target列表，从而向这些Target轮询监控数据。

然而，如果我们可能还需要：

• 按照不同的环境dev, stage, prod聚合监控数据？
• 对于研发团队而言，我可能只关心dev环境的监控数据，如何处理？
• 如果为每一个团队单独搭建一个Prometheus Server。那么如何让不同团队的Prometheus Server采集不同的环境监控数据？

面对以上这些场景下的需求时，我们实际上是希望Prometheus Server能够按照某些规则（比如标签）从服务发现注册中心返回的Target实例中有选择性的采集某些Exporter实例的监控数据。

接下来，我们实验如何通过Prometheus强大的Relabel机制来实现以上这些具体的目标。

Prometheus的Relabeling机制

在Prometheus所有的Target实例中，都包含一些默认的Metadata标签信息。可以通过Prometheus UI的Targets页面中查看这些实例的Metadata标签的内容：

默认情况下，当Prometheus加载Target实例完成后，这些Target时候都会包含一些默认的标签：

• __address__：当前Target实例的访问地址<host>:<port>
• __scheme__：采集目标服务访问地址的HTTP Scheme，HTTP或者HTTPS
• __metrics_path__：采集目标服务访问地址的访问路径
• __param_<name>：采集任务目标服务的中包含的请求参数

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

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

一般来说，Target以__作为前置的标签是在系统内部使用的，因此这些标签不会被写入到样本数据中。不过这里有一些例外，例如，我们会发现所有通过Prometheus采集的样本数据中都会包含一个名为instance的标签，该标签的内容对应到Target实例的__address__。 这里实际上是发生了一次标签的重写处理。

这种发生在采集样本数据之前，对Target实例的标签进行重写的机制在Prometheus被称为Relabeling。