Prometheus中动态发现Target和Relabel的应用

本文以Consul为例介绍了Prometheus的服务发现能力，适用于在云平台/容器平台的监控场景动态发现Target。同时通过Prometheus的relabel实现多数据中心的监控数据聚合，以及选择和过滤监控Target。

Prometheus中的Job和Instance

Prometheus主要由一下几个部分组成：

• Prometheus Server：负责采集监控数据，并且对外提供PromQL实现监控数据的查询以及聚合分析；

• Exporters：用于向Prometheus Server暴露数据采集的endpoint，Prometheus轮训这些Exporter采集并且保存数据；

• AlertManager以及其它组件（……和本文无关就不说这些）

在Prometheus Server的配置文件中我们使用scrape_configs来定义：

scrape_configs:
- job_name: prometheus
  metrics_path: /metrics
  scheme: http
  static_configs:
  - targets:
    - localhost:9090

其中每一个scrape_config对象对应一个数据采集的Job，每一个Job可以对应多个Instance，即配置文件中的targets。通过Prometheus UI可以更直观的看到其中的关系。

Pull vs Push

对于Zabbix以及Nagios这类Push系统而言，通常由采集的Agent来决定和哪一个监控服务进行通讯。而对于Prometheus这类基于Pull的监控平台而言，则由server侧决定采集的目标有哪些。

相比于Push System而言，Pull System：

• 只要Exporter在运行，你可以在任何地方（比如在本地），搭建你的监控系统

• 你可以更容器的去定位Instance实例的健康状态以及故障定位

当然对于我个人的角度来看，Pull System更利于DevOps的实施。每一个团队可以搭建自己的监控系统，并关注自己关心的监控指标，并构建自己的DevOps Dashboard。

在小规模监控或者本地测试中_static_configs_是我们最常用的用于配置监控目标服务，但是在IaaS平台（如Openstack）或者CaaS平台（如Kubernetes）中：基础设施、容器、应用程序的创建和销毁会更加频繁。

那对于Prometheus这样的Pull System而言，如何动态的发现这些监控目标？

服务发现 Service Discovery

Prometheus支持多种服务发现机制：文件、DNS、Consul、Kubernetes、OpenStack、EC2等等。基于服务发现的过程并不复杂，通过第三方提供的接口，Prometheus查询到需要监控的Target列表，然后轮训这些Target获取监控数据。

这里为了验证Prometheus的服务发现能力，我们使用Docker Compose在本地搭建我们的测试环境。我们使用gliderlabs/registrator监听Docker进程，对于暴露了端口的容器，registrator会自动将该容器暴露的服务地址注册到Consul中。

这里使用Node Exporter采集当前主机数据，使用cAdvisor采集容器相关数据。

完整的Docker Compose文件如下：

version: '2'
services:
  consul:
    image: consul
    ports:
      - 8400:8400
      - 8500:8500
      - 8600:53/udp
    command: agent -server -client=0.0.0.0 -dev -node=node0 -bootstrap-expect=