系统度量数据的收集方式通常分为拉动式（Pull）和推动式（Push）。这两种方式在数据采集和传输的过程中具有不同的特点和适用场景。
图片
1.拉动式
拉动式是指数据收集系统定期向目标设备或系统发送请求，以获取数据。这种方式的关键在于，数据收集方主动发起请求，目标系统被动响应。
图 1 显示了通过 HTTP 拉动模式收集数据的情况。我们有专门的指标收集器，定期从运行的应用程序中提取指标值。
在这种方法中，指标收集器（Metrics Collector）需要知道要从哪些服务端点获取数据。一种简单的方法是使用一个文件来保存 “指标收集器 ”服务器上每个服务端点的 DNS/IP 信息。虽然想法很简单，但这种方法在大规模环境中很难维护，因为服务器会经常添加或移除，而且我们要确保度量收集器不会错过从任何新服务器收集度量数据。
优点
- 控制灵活性：拉动式系统可以根据需求定期或按需请求数据，因此具有较高的控制灵活性。用户可以指定数据采集的时间或条件。
- 减少不必要的数据传输：只有在请求时才会收集数据，这意味着如果没有实际的需求或事件，数据不会被频繁地传输，从而避免了不必要的网络流量和存储。
- 简化处理：拉动式方式可以在数据请求时就进行数据处理，因此系统接收到的数据通常已被筛选或加工过。
缺点
- 延迟问题：因为数据是按需收集的，如果请求频率较低，可能会存在一定的延迟，不能即时获取最新的数据。
- 请求开销：每次数据请求都需要一定的系统资源和时间，特别是在数据量较大的时候，频繁请求可能会导致性能瓶颈。
- 系统负担：当多个设备或系统都使用拉动方式时，服务器可能需要处理大量的请求，从而导致压力增加。
我们可以通过 Kubernetes、Zookeeper 等提供的服务发现（Service Discovery）获得可靠、可扩展和可维护的解决方案，其中服务会注册其可用性，每当服务端点列表发生变化时，度量收集器就会收到服务发现组件的通知。服务发现包含有关何时何地收集度量的配置规则，如图 2 所示。
2.推动式
推动式是指数据源主动向数据收集系统发送数据。数据生成方（如设备、系统）在事件发生或数据更新时，主动将数据推送到接收方。
第一步
指标收集器从服务发现获取服务端点的配置元数据。元数据包括拉取间隔、IP 地址、超时和重试参数等。
第二步
指标收集器通过预定义的 HTTP 端点（例如 /metrics）获取指标数据。要公开该端点，通常需要在服务中添加客户端库。在图 3 中，服务是 Web 服务器。
第三步
另外，度量收集器还可以向服务发现（Service Discovery）注册变更事件通知，以便在服务端点变更时接收更新。或者，度量收集器可以定期轮询端点变化。
优点
- 实时性强：数据能够在生成或变化的瞬间被推送到接收方，这种方式适合需要高实时性的数据场景，如监控系统或实时分析。
- 减少请求开销：由于数据是被主动推送的，收集系统不需要周期性地发送请求，减少了系统间的通信开销。
- 灵活的事件驱动：可以根据特定的事件或条件触发数据推送，而不是基于时间，这使得数据采集更加精确和高效。
缺点
- 数据过载：如果推送过于频繁，可能会导致数据过载，尤其是在高频变化的场景下，接收方可能难以处理过多的数据。
- 管理复杂性：在推送式数据收集模式下，数据源需要管理发送的频率和触发条件，系统间需要保持较强的同步和协调，否则可能会发生数据丢失或重复传输。
- 网络负担：如果数据推送过于频繁或数据量较大，可能会给网络带来负担，尤其在网络带宽有限的情况下。
