云端的应用在资源的使用上具有动态性的特点，可以更加容易地进行横向扩容甚至自动扩容，使得用户根据需求进行资源的购入成为可能，而传统的监控是资源特定情况下进行，为了更好地让使用者对于自身资源和系统状况进行把握和预测，需要结合一些服务发现机制进行监控，这篇文章进行简单地总结和介绍。
Pull模式 vs Push模式
Prometheus推荐使用Pull模式，但是也支持Push模式。Pull还是Push，主要的区别在于数据搜集的主体执行者：
- Pull模式：由Prometheus Server根据配置，定期从提供监控数据地址去 “Pull” 相应的监控对象数据，比如从Node Exporter那里获取节点的监控信息。
- Push模式：从数据的流向的发起来看是从监控对象侧进行主动的数据提供，但是是通过pushgateway作为中间代理的角色，这种模式下增加了pushgateway的角色，首先由监控对象侧将数据发给pushgateway，然后Prometheus Server定期从pushgateway处获取相应的数据。
Push模式的场景示例：
一般情况下，使用Prometheus进行监控使用的是Pull模式，而Push模式主要是针对Prometheus server不方便或者无法直接从监控对象侧获取相应的数据。比如：
- 监控对象侧没有直接提供相应的/metrics可以获取的监控数据，但是监控数据可以使用另外的形式推送至pushgateway
- Prometheus Server无法使用Pull的方式直接获取监控对象的数据，比如布置在不同网段，这时往往需要pushgateway这样的中间代理角色来辅助
静态配置 vs 动态配置
- 静态配置
Prometheus通过static_configs来设定静态方式的监控对象，比如如下Node Exporter的监控数据抓取的配置，其特点是Node Exporter提供的监控数据的/metrics的HTTP服务的IP和端口号都是固定的，在这种情况下可以使用静态配置
scrape_configs:
- job_name: 'node_exporter'
static_configs:
- targets: ['192.168.31.242:9100']
- 动态配置
动态配置是相较于静态配置的说法，在Prometheus中则是结合服务发现来实现的，将服务发现的这个功能和机制分离出去，直接利用现有的服务发现的功能框架比如consul来确认可能会动态变化的监控对象，这样就做到了所谓的动态配置。
常见的动态配置的使用方式如上图所示： - 1: 各种服务直接在SD（服务发现能力提供者：比如consule）上进行服务注册
- 2: Prometheus不直接管理哪些对象需要监控，它直接向SD去获取需要监控的对象的列表
- 3: SD会返回给Prometheus需要监控的对象列表
- 4: Prometheus根据返回的监控对象列表使用Pull的方式进行监控数据的收集
这样，通过集成一个服务注册和管理的组件就实现了资源动态变化情况下的对应方式。
机制：基于文件的服务发现
动态配置的核心是服务发现机制，而如何进行服务的注册和发现，最简单的方式莫过于基于文件的服务发现机制。比如又如下场景：
使用场景示例：
使用Node Exporter作为监控数据的提供者，Prometheus会定期从Node Exporter中获取数据，但是由于其IP和Port可能会发生变化，写在ConfigMap中使用static_configs的方式对应已经比较麻烦了，比如需要修改相应的设定，更新Prometheus使用的ConfigMap。
使用基于文件的服务发现机制，Prometheus的配置文件示例如下所示：
scrape_configs:
- job_name: 'node_exporter'
file_sd_configs:
- refresh_interval: 5m
- files:
- node_exporter.json
可以看到，相较于静态方式的static_configs，这里使用的是file_sd_configs方式，在配置文件中不再出现Node Exporter的IP和端口号，取而代之的是存放了IP和端口号的JSON文件的名称（node_exporter.json）。
[
{
"targets": [ "192.168.31.242:9100"],
"labels": {
"job": "node_exporter"
}
}
]
- refresh_interval: Prometheus会定期的监控node_exporter.json以获得变化后的Node Exporter的端口号，比如这里设定为5分钟，每5分钟Prometheus就会确认一下监控对象的详细信息，然后按照此详细信息进行收集，从而实现了动态变化的对应。
机制：基于Consul的服务发现
Consul提供了服务发现和注册的功能，而Prometheus也支持通过Consul的方式来进行动态配置，
consul_sd_configs:
- server: Consul服务的IP:Consul服务的端口号
services:
- node_exporter
而关于Node Exporter相关信息的变化则是Consul需要管理的内容，而Prometheus只需要于Consul进行交互获取这些信息即可。向Consul中注册Node Exporter的内容本文不再赘述。
