1.4.2　监控检查的两种模式——拉取和推送

监控系统执行监控检查的模式主要有拉取（Pull）和推送（Push）两种。这两种模式究竟哪种更好？对此，监控领域内部存在相当大的争议。

拉取模式（简称拉模式），是一种从监控对象中通过轮询获取监控信息的方式。拉模式更多拉取的是采样值或者统计值，由于有拉取间隔，因此并不能准确获取数值状态的变化，只能看到拉取间隔内的变化，因此可能会产生一些毛刺现象，需要进一步进行数据处理。监控和性能测试更关注p95/p99位的原因就是存在长尾效应。数据采集过程中对数据进行的定义、采样、去尖刺等处理操作也是非常重要的，这部分内容我们会在后续章节详细介绍。

拉模式的优点是告警可以按照策略分片，告警模块只需要拉取自己需要的数据，且可以完美支持聚合场景；拉模式的缺点在于监控数据体量非常庞大，对存储有较高的要求，实战中可能还需要考虑数据的冷热分离。

推送模式（简称推模式），是应用程序基于事件主动将数据推向监控系统的方式。推模式的优点是实时性好，一旦触发一个事件就可以立刻收集发送信息。但是推模式的缺点也很明显，由于事件的不可预知性，大量的数据推送到监控系统，解析和暂存会消耗大量的内存，这可能对监控的进程产生影响。由于消息是推送过来的，所以主动权在推送方。在这种模式下，由于网络等迟迟没有得到确认，所以在ack等情况下很容易造成数据重复。这是因为推模式在进行推送中，如果发送失败，为了防止内存撑爆，系统会将数据持久化到文件或者队列。因此采用推模式时，若产生了重复数据，就需要进行去重等操作，对于这些技术细节，需要仔细打磨。

Prometheus在收集数据时，主要采用拉模式（服务端主动去客户端拉取数据），当然它也支持接收推送到Pushgateway的事件；而以Zabbix为代表的传统监控系统采用推模式（客户端发送数据给服务端）。拉模式在云原生环境中有比较大的优势，原因是在分布式系统中，一定是有中心节点知道整个集群信息的，那么通过中心节点就可以完成对所有要监控节点的服务发现，此时直接去拉取需要的数据就好了；推模式虽然可以省去服务发现的步骤，但每个被监控的服务都需要内置客户端，还需要配置监控服务端的信息，这无形中加大了部署的难度。推模式在OpenStack和Kubernetes等环境中使用比较少。