集装箱领域十种监控系统的比较

发布时间:2020-05-30 09:36:10

集装箱监控环境有多种形式和大小。有些是开源的,而另一些是商业的。有些可以通过单击平台(例如,在rancher容器管理平台的应用程序目录中)进行部署,而另一些则需要手动配置。有些是通用的,有些是特定于容器环境的。有些托管在公共云中,而另一些则需要安装在自己的集群主机上。

集装箱监控环境有多种形式和大小。有些是开源的,而另一些是商业的。有些可以通过单击平台(例如,在rancher容器管理平台的应用程序目录中)进行部署,而另一些则需要手动配置。有些是通用的,有些是特定于容器环境的。有些托管在公共云中,而另一些则需要安装在自己的集群主机上。

本文将对集装箱领域的10种监控方案进行综合分析和比较。监测解决方案的数量令人望而生畏。新的解决方案正在出现,而现有的解决方案正在演变。我没有深入研究每个解决方案,而是采用了一种比较方法。这样,读者可以“缩小范围”,更仔细地评估自己的需求,从而选择最合适的解决方案。

本文介绍和比较的监测方案包括:

本文将介绍前五种解决方案。在接下来的章节中,我提出了一个比较监控解决方案的架构,并对每个解决方案进行了高层比较,然后通过讨论每个解决方案将如何与rancher一起工作来更详细地讨论每个解决方案的细节。我还将讨论一些其他的监控解决方案。这些解决方案不包括在本文的“前十个”中,但您可能已经遇到过它们。

客观比较监视解决方案的一个挑战是,该解决方案的体系结构、功能、部署模型和成本可能有很大的差异。一个解决方案可以从单个主机提取和绘制docker相关数据,另一个解决方案可以从多个主机收集数据,测量应用程序响应时间,并在特定条件下发送自动警报。

在比较解决方案时,首先确定一个比较架构,这将对以后的比较工作带来很大的帮助。我任意提出了下图所示的比较架构,它基于大多数监控解决方案的功能层。这种比较架构可分为七层:

主机代理-主机代理表示从各种源(如API和日志文件)提取时间序列数据的监视解决方案的“分支”。主机代理通常安装在每个集群主机上(无论是本地主机还是云主机),它们通常打包为docker容器以进行部署和管理。

数据收集体系结构,—虽然单主机数据有时很有用,但管理员可能需要所有主机和应用程序的统一视图。监视解决方案通常具有从每个主机收集数据并将其存储在共享数据存储中的机制。

数据存储-数据存储可能是传统数据库,但更常见的形式是可伸缩的分布式数据库,它优化由键值组成的时间序列数据。一些解决方案具有本机数据存储,而其他解决方案则使用开源数据存储插件。

聚合引擎-要存储来自数十台主机的原始数据,您可能会遇到的主要问题之一是数据量太大。监控架构通常提供数据聚合功能,将原始数据转换为统一的度量(如小时或每日摘要),清除不再需要的旧数据,或以某种方式重新分解数据,以支持预期的查询和分析。

过滤和分析-监控解决方案就像从数据中获得的洞察力。在不同的监控解决方案之间,过滤和分析的能力往往非常不同。一些解决方案只支持一些简单时间序列图形式的预打包查询,而其他解决方案则具有可定制的仪表板、嵌入式查询语言和复杂的分析功能。

可视化层-监控工具通常有一个可视化层,用户可以在其中与web界面交互以生成图表、制定查询,在某些情况下还可以定义警报条件。可视化层可以与过滤和分析功能紧密耦合,也可以根据解进行分离。

警报和通知-很少有管理员有时间整天坐在那里盯着监控图表。监控系统的另一个共同特点是报警子系统。如果达到或超过预定义的阈值,则可以通知管理员。

用户在选择监控解决方案时,除了了解每个监控解决方案如何实现上述基本功能外,还应注意和考虑以下几个方面:

下图以高层的形式展示了我们提出的10个监控解决方案如何对应于我们在上面提出的七层比较模型,哪些组件实现了每一层的功能,以及组件的位置。每个框架都非常复杂。下图中的比较方法无疑是一种简化,但它也将为理解每个组件的功能提供一个有用的视角。

下面的摘要描述了每个监视解决方案的其他属性。其中一些解决方案有多种部署选项,因此它们之间的对比变得更加微妙。

Dockerstats本身的用途有限,但docker统计可以与其他数据源(如docker日志文件和docker事件)结合使用,以满足的监控服务。Docker只能获取一台主机上报的数据,因此dockerstats使用多主机应用服务或swarm群集监控kubernetes的能力有限。由于没有可视化的界面、聚合、数据存储和来自多个主机的数据收集,docker的统计数据不适合我们的七层模型。由于rancher在docker上运行,rancher用户可以自动使用基本的dockerstats功能。

C advisor有一个可以生成多个图表的web界面,但是和dockerstats一样,它只监视一个docker主机。它可以作为容器安装在docker机器上,也可以安装在docker主机本身上。

管理员可以很容易地在rancher上部署C advisor,它是几个集成监视堆栈的一部分,但是C advisor不再是rancher本身的一部分。

我们提到scout是因为在比较监控docker的解决方案时,前面提到了它。scout通过灵活的报警和与第三方报务的集成,提供全面的数据采集、过滤和监控功能。

Scout的团队提供了如何使用Ruby和statsd编写脚本的说明,以使用dockerstats API、dockerventapi和传递数据来监视这些脚本。他们还打包了一个docker scout容器,可以在dockerhub(scout应用/docker scout)上使用,这使得安装和配置scout代理更加容易。易用性取决于用户是自己配置statsd代理,还是使用打包的docker scout容器。

作为托管云服务,scout应用在快速启动和运行容器监控解决方案时可以节省很多麻烦。如果您正在部署Ruby应用程序或运行scout支持的数据库环境,使用scout解决方案可以帮助您集成docker、应用程序和数据库级监控。

然而,用户可能需要注意一些事情。在大多数服务级别,平台只允许30天的数据,而不是每个受监视的主机。至于价格,每个月定价的标准套餐从99美元到299美元不等。这种开箱即用的解决方案只能提取和传递有限的指标,不适用于kubernetes相关监测。此外,虽然docker Scout在dockerhub上可用,但开发是由Pingdom完成的。在过去的两年里,scout的代理组件只更新了一点。

Rancher本身默认不支持scout,但由于scout是一个云服务,因此在Rancher中很容易部署和使用,特别是在使用基于容器的代理时。目前,docker scout代理不在rancher应用程序目录中。

Pingdom之所以值得关注,是因为其灵活的定价方案似乎更适合监控docker环境。用户可以根据计划收集的statsd数据的数量(每月每10个数据中就有1个数据)在基于每台服务器的计划之间进行选择。Pingdom易于设置和管理。它非常适合需要完整监控解决方案并希望监控容器管理平台之外的其他服务的用户。与scout一样,Pingdom也是一种云服务,很容易与rancher一起使用。

虽然datadog本身不支持rancher,但rancher UI中有一个datadog目录。用户可以在rancher上轻松安装和配置datadogagent。用户还可以使用rancher标记,datadog中的报告反映了您在rancher中用于主机和应用程序的标记。与前面提到的云服务相比,datadog可以提供更好的数据访问权限和更精确的警报条件定义。与其他服务一样,datadog可以用于监视其他服务和应用程序,它有200多个集成库。Datadog还保留了18个月的全分辨率数据,比云服务更长。

与其他云服务相比,datadog的优势在于它具有docker以外的集成功能,可以从kubernetes、mesos、etcd和运行在您的牧场主环境中的其他服务收集数据。这种多功能性对于在rancher上运行kubernetes的用户非常重要,因为他们希望能够监视kubernetespods、服务、名称空间和kubelethealth等数据。datadog-kubernetes监控解决方案可以通过kubernetes中的守护进程将数据收集代理自动部署到每个集群节点。

datadog的价格为每台主机每月15美元左右,总价格将根据用户需要的服务和每台主机监控的容器数量而增加。