概念

已经知道prometheus是基于pull形式进行数据采集，prometheus可以通过静态配置更新监控的目标，但这样势必带来巨大的运维开销。如何实现服务的自动发现，这就需要引入中间人（服务注册中心），这就是服务发现：

服务发现

基于文件的服务发现

通过创建target.json文件，将所有的target配置在target.json，在需要更新target的时候，只需要更新target.json，格式如下：

[
  {
    "targets": [ "localhost:8080"],
    "labels": {
      "env": "localhost",
      "job": "cadvisor"
    }
  }
]

在prometheus启动的时候，通过--config.file指定配置文件prometheus.yml，格式如下：

global:
  scrape_interval: 15s
  scrape_timeout: 10s
  evaluation_interval: 15s
scrape_configs:
- job_name: 'file_ds'
  file_sd_configs:
  - refresh_interval: 1m
  - files:
    - targets.json

其中refresh_interval指定了定时读取target.json的时间间隔。

这种方式虽然解决了不需要修改prometheus.yml的问题，但是问题改成了需要运维维护target.json，没根本解决问题。

基于Consul的服务发现

关于Consul的介绍这里不多介绍，我们只需知道，Consul是一个服务配置、发现的中间件。

在基于文件的服务发现中提到，target的更新需要修改target.json，本质上没有解决运维操作的步骤。而基于Consul的服务发现，则是通过节点主动注册信息到Consul，prometheus通过和Consul集成，从Consul中以http协议获取target的信息，集成见prometheus.yml部分配置：

- job_name: consul_sd
    metrics_path: /metrics
    scheme: http
    consul_sd_configs:
      - server: ${consul_ip}:8500
    relabel_configs:
    # 删除consul自身
    - source_labels: [__meta_consul_service]
      regex: '^consul$'
      action: drop
    #元数据信息添加到job标签
    - source_labels: [__meta_consul_service]
      target_label: "job"

缺点

需要引入额外的中间件consule
需要与target集成，在target启动时，需要在consul上进行注册

其他动态的服务发现

azure_sd_config ：从Azure的vm上拉取配置
dns_sd_config: 基于dns的服务发现

对比

方式	优点	缺点	依赖项	是否建议
基于文件的服务发现	1、简单	1、没解决根本问题，不能采用		不建议采用
基于Consul的服务发现	1、便于运维	1、需要target集成sdk，在sdk中向consul注册节点信息	consul集群	建议采用
其他服务发现	1、便于运维	1、依赖资源层环境		不建议采用
使用pushgateway	1、便于运维	1、需要target集成sdk，在sdk中定时上报指标 2、单点问题，需要借助nginx实现多机部署		可以考虑