首先，官方文档的 FAQ 是这么解释为何使用拉取（pull）而不是推送（push）模式：
- 可以在笔记本上监控开发时产生的变更
- 如果监控目标宕了可以更容易发现
- 可以通过web浏览器手工访问监控目标并检查其健康状况
总之我们认为拉取比推送好一点点，但是这并不一个监控系统需要考虑的重点。
下文是一篇 Prometheus 官方博客的阅读笔记。
有些人认为拉取模式是无法扩展的，然而这和我们的实践经验相反，以下进一步讨论这一误解。
Prometheus 不是 Nagios
Nagios 有扩展性不好的名声，这部分源于在Nagios主机上要创建用于检查的子进程，这些子进程执行随机操作来探测节点和服务的健康状况，这造成Nagios中心节点的压力迅速升高。于是人们通常为间隔几分钟执行一次这种检查。
而 Prometheus 采取了完全不同的方式，它不执行检查脚本，而仅仅通过网络收集被控目标的时序数据。对每个被控目标，Prometheus服务器简单地通过HTTP（高并发，使用goroutines）收取所有指标的当前状态，没有任何其他的运行负荷。这引出下一点
谁发起连接无关紧要
对于扩展性而言，服务器和被控端哪一端发起TCP连接无关紧要，创建连接的开销比传输的指标负载要小。
推送模式可以使用UDP来避免创建连接，诚然，但是TCP/HTTP开销与Prometheus服务器的注入数据（尤其是持久化时序数据到硬盘）的工作比起来是微不足道的。一些数据：一个单节点Prometheus服务器可以轻松存储数百万时序数据，每秒80万样本数据。设刮取周期为10秒，每个被控端700个时序指标，这允许你用一台Prometheus服务器监控超过1万台主机。扩展的瓶颈绝对不是拉取模式，而通常是Prometheus服务器注入数据到内存然后持久化到硬盘的速度。
而且鉴于网络的可靠性，使用基于TCP的拉取模式使指标数据的到达非常可靠，如果由于网络原因导致指标传输失败时，监控系统也可以立刻发现。
Prometheus 不是基于事件的系统
有些监控系统是基于事件的，每一个事件（HTTP请求、异常）发生时他们立即向监控服务器报告。监控服务器可以汇聚事件为指标或保存事件用于后续处理（ELK）。对于这种系统，拉取确实是有问题的，计量服务必须在拉取的间隔中间缓存事件，拉取的频率也要非常高才能接近推送模式的效果。
Prometheus不是基于事件的监控系统，它仅仅关心标准化地采集给定指标的当前状态，而不是导致这些指标的底层事件。例如，计量服务不会发送关于每个HTTP请求的消息给Prometheus服务器，而是在内存中简单地累加这些请求。每秒可能会发生成百上千次这种累加而不会产生任何监控流量。Prometheus然后每隔15或30秒简单地问一下这个服务实例当前状态的累积值而已。监控结果的传输量很小，拉取模式也不会产生问题。
但是现在监控需要知道我的服务实例！
基于拉取模式的监控系统需要知道存在哪些服务实例和如何连接到它们。有些人担心这会导致很大的配置量从而限制扩展性。
对于严格的监控系统，无论如何都无法逃避这些配置工作，推送模式会要求更多的配置，因为服务器要知道被控端，被控端还要知道服务器。拉取模式不但需要的配置量更少，而且配置更灵活。当被控端点移动以后，不需要重新配置被控端。你也可以简单地copy一个生产环境的监控到你的笔记本上。你还可以通过其他手段或者手工检查被控端。
Prometheus有方便地配置界面，内置支持广泛的云服务厂商的服务发现机制。
监控中偶尔遭遇DDoS
无论那种模式，发送给时序数据库的数据量超过它的处理能力就会导致它宕机。推送模式更容易导致这种情况发生，相比而言拉取模式地风险更低一些
真实世界的证明
Google就用它，你还能比Google的服务器规模大么？
拉取模式还是存在问题的
一个突出的问题是server和被控端的网络不可达，此时Prome也有变通的推送网关模式。这主要是TCP网络操作的困难性导致的。