系统监控数据该用推还是拉？

系统度量数据的系统收集方式通常分为拉动式（Pull）和推动式（Push）
。这两种方式在数据采集和传输的监控过程中具有不同的特点和适用场景 。

图片

1.拉动式

拉动式是数据指数据收集系统定期向目标设备或系统发送请求，以获取数据。该用这种方式的推还关键在于，数据收集方主动发起请求
，系统目标系统被动响应。监控

图 1 显示了通过 HTTP 拉动模式收集数据的数据情况。我们有专门的该用指标收集器 ，定期从运行的源码下载推还应用程序中提取指标值。

在这种方法中
，系统指标收集器（Metrics Collector）需要知道要从哪些服务端点获取数据
。监控一种简单的数据方法是使用一个文件来保存 “指标收集器 ”服务器上每个服务端点的 DNS/IP 信息
。虽然想法很简单，该用但这种方法在大规模环境中很难维护，推还因为服务器会经常添加或移除，而且我们要确保度量收集器不会错过从任何新服务器收集度量数据。

优点

控制灵活性 ：拉动式系统可以根据需求定期或按需请求数据，因此具有较高的控制灵活性 。用户可以指定数据采集的时间或条件。源码库减少不必要的数据传输：只有在请求时才会收集数据 ，这意味着如果没有实际的需求或事件，数据不会被频繁地传输，从而避免了不必要的网络流量和存储。简化处理：拉动式方式可以在数据请求时就进行数据处理 ，因此系统接收到的数据通常已被筛选或加工过。

缺点

延迟问题 ：因为数据是按需收集的，如果请求频率较低
，可能会存在一定的延迟，建站模板不能即时获取最新的数据。请求开销：每次数据请求都需要一定的系统资源和时间，特别是在数据量较大的时候，频繁请求可能会导致性能瓶颈 。系统负担：当多个设备或系统都使用拉动方式时，服务器可能需要处理大量的请求，从而导致压力增加。

我们可以通过 Kubernetes、Zookeeper 等提供的服务发现（Service Discovery）获得可靠、可扩展和可维护的云计算解决方案，其中服务会注册其可用性，每当服务端点列表发生变化时 ，度量收集器就会收到服务发现组件的通知 。服务发现包含有关何时何地收集度量的配置规则，如图 2 所示。

2.推动式

推动式是指数据源主动向数据收集系统发送数据。数据生成方（如设备、系统）在事件发生或数据更新时 ，主动将数据推送到接收方。

第一步

指标收集器从服务发现获取服务端点的配置元数据
 。元数据包括拉取间隔 、免费模板IP 地址、超时和重试参数等。

第二步

指标收集器通过预定义的 HTTP 端点（例如 /metrics）获取指标数据 。要公开该端点，通常需要在服务中添加客户端库
 。在图 3 中
，服务是 Web 服务器。

第三步

另外
，度量收集器还可以向服务发现（Service Discovery）注册变更事件通知，以便在服务端点变更时接收更新 。或者，度量收集器可以定期轮询端点变化。

优点

实时性强：数据能够在生成或变化的瞬间被推送到接收方，高防服务器这种方式适合需要高实时性的数据场景 ，如监控系统或实时分析。减少请求开销 ：由于数据是被主动推送的
，收集系统不需要周期性地发送请求
，减少了系统间的通信开销。灵活的事件驱动：可以根据特定的事件或条件触发数据推送
，而不是基于时间 ，这使得数据采集更加精确和高效
。

缺点

数据过载 ：如果推送过于频繁，可能会导致数据过载，尤其是在高频变化的场景下，接收方可能难以处理过多的数据。管理复杂性：在推送式数据收集模式下，数据源需要管理发送的频率和触发条件，系统间需要保持较强的同步和协调
，否则可能会发生数据丢失或重复传输。网络负担 ：如果数据推送过于频繁或数据量较大 ，可能会给网络带来负担，尤其在网络带宽有限的情况下
。

很赞哦!（6）