监控系统数据采集模式推和拉

介绍

在考虑如何将度量采集到监视系统中时，有两种不同的思想流派：要么客户端（被监控对象）将度量推送（通常通过UDP）到系统中，要么服务器（监控系统）将它们拉取（通常通过HTTP）到系统中。在某些地方说“基于推送或拉取的系统”以使文章简洁时，我可能不会提到这一点。

push方法用于Graphite等系统，而pull方法用于Prometheus等监视系统。

哪一个更好？就像生活中的一切一样，没有明确的答案，双方都有很强的理由支持他们。我将尝试了解它们。

争论

支持拉：更容易控制数据的真实性和数量

当提取数据时，由于服务器本身是发起连接的服务器，因此我们可以确定数据的真实性。我认为这使数据路径更加清晰，因为当今大多数用户的公共IP地址后面都有路由器，因此我们很容易会误解数据是否真正来自。

让我尝试澄清这一点。对于基于TCP拉式的系统，需要直接访问度量，即，度量数据可用的端口始终在侦听，而在基于推的系统中，使用临时连接，这些连接会消失并很快出现。

而且，由于预先知道从中收集度量数据的确切目标，因此可以更轻松地计划基于拉式系统的容量。另一方面，在基于推送的系统上，任何类型的系统都可以推送到度量标准收集服务器。可以通过使用服务器白名单来解决此问题，从该服务器接受数据，但大多数基于推送的系统均不支持。另外，我们正在考虑两个不同模型的特征，而不是它们的实现。

支持推送：更容易实现对不同摄入点的复制

由于所有操作都是由客户端本身启动的，因此将相同的流量复制到不同的服务器变得更加容易。您只需要将其传输到多个目标IP地址即可。

基于推送的最流行的监视系统之一Graphite在其网站上具有以下内容：

它的组成部分之一-Carbon-具有复制因子，中继方法等内容，这使得开始进行此类操作变得容易。这样做比站起来另一个实例（例如Prometheus）要容易得多。

另外，请考虑所有接收器将获得相同的准确数据这一事实。如果您要启动两个不同的Prometheus实例（使用HTTP pull方法），则它们很可能将没有相同的确切数据。

首先，时间戳会有所不同。对于Graphite，时间戳必须在数据内部编码（在Prometheus中是可选的）。此外，时间序列的值很可能会有所不同，因为由于在开始刮刮时增加了抖动，因此刮刮的大部分时间不会同时发生。

支持拉动：更容易加密流量

将TLS终止反向代理置于提供度量标准的普通HTTP服务器之前非常容易，如果它是面向公众的系统或来自私有CA的证书，我们甚至可以使用letsencrypt之类的方法自动获取证书内部网上的每个人都信任。像Caddy这样的软件使它变得尽可能容易。

是的，也可以使用客户端TLS，但是它容易出错，并且给代码库增加了很多混乱。你会喜欢什么：

• 您代码中的简单HTTP服务器，或者…
• 是否支持客户端TLS的客户端连接到另一台服务器，以将指标发送到该服务器？

大多数人会选择第一个选项。为什么在客户端软件上执行此加密是一个坏主意的原因，与通常在客户端TLS上执行错误的原因相同。例如，您可以查看本文的原因。此外，本答案由多项式＃2：

主要原因是95％的互联网用户不知道客户端证书是什么，更不用说如何使用它了。有些用户勉强可以使用用户名和密码，而大多数用户仍然不用担心双重身份验证。将客户端证书安装在单独的设备（台式机，笔记本电脑，平板电脑，智能手机等）上以对单个服务进行身份验证也很麻烦。

我认为程序员或多或少都适用于同样的故事。而且，我们也希望将这种加密复杂性从客户端代码移到单独的服务器中。这仅对于基于拉的模型是可行的。

支持推送：易于建模寿命短的批处理作业

在push方法中，客户端本身将度量标准推送到服务器。另一方面，在拉方法中，服务器会定期探测客户端并收集其指标。在普罗米修斯，这称为刮擦期。这会带来（痛苦的）结果-如果客户端的生存期不超过该时间段，则指标将丢失。此图说明了循环的工作方式，例如：

在push方法中，我们对此没有问题，因为只要批处理作业完成，我们就可以发送指标。当然，普罗米修斯试图解决这个问题。我们拥有所谓的 Pushgateway。

本质上，它是度量标准的接收者，该度量标准会定期被Prometheus中的Prometheus aka Graphite刮取。它的工作方式也与石墨出口商相同 。

但是，它们有自己的问题。例如，如果推送网关出现故障，指标可能会消失。否则，如果客户端更新它们的速度比Prometheus抓取它们的速度足够快，则度量值可能会丢失。

推方法和Graphite（扩展）不会遇到此问题。

支持拉取：更轻松地按需检索数据（和调试）

在TCP（HTTP）之上具有pull方法意味着很容易按需检索数据并调试问题。特别是，如果度量数据像Prometheus所使用的格式一样易于阅读且易于理解。

这使您有机会轻松地区分客户端和服务器端的错误。在push方法中，我们的双手会被绑在背后，因为如果我们没有收到任何指标，则意味着两件事之一：

• 网络有问题
• 客户有问题

使用push（TCP / HTTP）方法，我们只需通过Web浏览器转到可以找到指标数据的IP地址和端口，就可以轻松地在这两者之间进行检查。

如果我们要重置TCP连接，则意味着网络正常，但是客户端出了点问题。如果我们什么都没得到回应，那意味着网络出了点问题。当然，这取决于客户端在关闭端口时发送回TCP_RST，但这就是大多数计算机的行为。

有利于推动：可能会更有表​​现

推方法通常使用UDP，而拉方法则基于TCP（HTTP）。这意味着我们有可能更有效地推动指标而不是拉动指标。这是由于以下事实：管理UDP连接的开销更少。例如，不需要检查您发送给对等方的消息是否已实际收到并且以正确的顺序接收。

但是，随着对TCP的支持已经渗透到许多商用网卡中，并且使用硬件加速的操作系统无处不在，例如，开销可能不像90年代那样大。

结论

这两种模型都各有利弊。但是，基于拉的模型似乎可以胜出，因为它提供了更高的可靠性（尤其是在谈论非常大规模的部署时），并且它仅需要很少的解决方法即可满足所有可能的度量收集需求案件。

诸如Prometheus之类的系统成为Borgmon监视系统的后代非常流行的原因可能并非没有原因。而且，众所周知，Borgmon被用来监视Google称为Borg的工作调度系统，后来成为大家都知道并喜欢的系统Kubernetes。

 

原文地址：https://blog.csdn.net/allway2