容器领域的十大监控系统对比(上）

Posted 2020-10-24

容器监测环境有多种形态和大小。有些是开源的，而另一些则是商业性质的。有些可以借助平台一键部署（例如在Rancher容器管理平台的应用目录中一键部署这些监控应用），而另一些则需要手动配置。有些是通用的，有些是专门针对容器环境的。有些托管在公有云中，而另一些则需要在自己的集群主机上安装。

在本文中，我将对容器领域的10个监控解决方案进行全面的分析对比。监控解决方案的数量之多令人望而生畏。新的解决方案不断涌现，同时现有的解决方案不断发展。我没有深入研究每个解决方案，而是采取了high-level的对比方法。通过这种方法，读者可以“缩小列表”，并能针对自身需求进行更认真的评估，从而选出最适合的解决方案。

 

本文将介绍并对比的监控解决方案包括：

● 原生Docker

● cAdvisor

● Scout

● Pingdom

● Datadog

● Sysdig

● Prometheus

● Heapster / GrafanaPingdom

●  ELK

●  Sensu

在本篇中将介绍前5个解决方案。

在以下章节中，我提出了一个对比监控解决方案的架构，并对每个解决方案进行了高级对比，然后通过讨论每个解决方案将如何与Rancher协同工作，从而更详细地讨论每个解决方案的细节。我还会在最后谈谈一些其它的监控解决方案，这些方案未被纳入本文的“十大”中，但你也可能遇到过。

对比架构

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

 

在对比解决方案时，先确定一个对比架构，将会为后期的对比工作带来很大帮助。我有些武断地提出了如下图的对比架构，以大多数监控解决方案都具有的功能层,来作为我对比的基础。这个对比架构可以分为7层：

主机代理——主机代理代表监控解决方案的“肢体”，它会从各种来源（如API和日志文件）提取时间序列数据。主机代理通常安装在每个集群主机上（无论是本地还是云端），并且它们通常被打包成Docker容器，以便部署和管理。

 

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

 

数据存储——数据存储可能是传统的数据库，但更常见的一种形式是可伸缩的分布式数据库，由键值对组成的时间序列数据进行了优化。有些解决方案具有原生数据存储，而其他解决方案则使用的是开源的数据存储插件。

 

聚合引擎——要存储来自数十个主机的原始数据，可能遇见的一大问题是数据量会变得过大。监控架构通常提供数据聚合功能，定期将原始数据转换为统一的度量标准(比如每小时或每日进行汇总)，清除不再需要的旧数据，或以某种方式重新分解数据，以支持预期的查询和分析。

 

过滤和分析——一个监控解决方案就像是你从数据中获得的洞察力。不同的监控解决方案之间，筛选和分析的能力常常差别很大。有些解决方案仅支持以简单的时间序列图表的形式来进行一些预先打包的查询, 而另一些则具有可自定义的仪表板、嵌入式查询语言和复杂的分析功能。

 

可视化层——监控工具通常具有可视化层，用户可以在其中与 web 界面进行交互以生成图表、制定查询以及在某些情况下定义警报条件。可视化层可能与筛选和分析功能紧密耦合, 也可能根据解决方案而与其分开。

告警和通知——很少管理员有时间整天坐着、时刻关注监控图表。监控系统的另一个常见特性是告警子系统，如果达到或超过了预定义的阈值，可以向管理员发出通知。

除了解每个监控解决方案如何实现上述基本功能之外，如下方面也是用户在选择监控解决方案时应该注意与考量的：

> 解决方案的完整性

> 是否易于安装和配置

> 关于web用户界面的详细信息

> 是否能够将警报转发至外部服务

> 社区支持和参与程度（若该方案为开源项目）

> Rancher应用程序目录中的可用性

> 支持监控非容器环境和应用程序

> 原生Kubernetes支持（Pods、Services、Namespaces等）

> 可扩展性（API，其他接口）

> 部署模式（自主托管、云上托管）

> 成本

10大监控解决方案的对比

下图以high-level的形式展示了我们提出的的10个监控解决方案如何对应我们在上文提出的七层对比模型，哪些组件实现了每层功能，以及组件的所在位置。每个框架都是极其复杂的，下图的对比方式毋庸置疑是一种简化，不过它也会给大家提供一个有用的视角来了解各个组件的功能。

下图的摘要介绍了每个监控解决方案的附加属性。其中某些解决方案有多个部署选项，所以它们之间的对比就变得更加细微。

每个解决方案的深入研究

DOCKER STATS

https://www.docker.com/docker-community

Docker通过docker stats命令为Docker主机提供了内置命令监控功能。管理员可以查询Docker守护进程，并获取有关容器资源消耗数据的详细实时信息，包括CPU和内存使用、磁盘和网络I/O以及正在运行的进程数。Docker stats利用Docker引擎API来检索这些信息。Docker统计信息没有历史概念，它只能监控单个主机，但聪明的管理员可以编写脚本从多个主机收集数据。

 

Docker stats本身用处有限，但Docker统计数据可以与其他数据源（如Docker日志文件和Docker事件）结合使用，以满足更高级别的监控服务。Docker只能得到单个主机报告的数据，所以Docker stats对于使用多主机应用程序服务的Kubernetes或对Swarm集群进行监控的能力有限。由于没有可视化界面，没有聚合，没有数据存储，也无法从多个主机收集数据，所以Docker的统计数据对我们的七层模型来说并不太适用。由于Rancher在Docker上运行，Rancher用户可以自动使用基本的docker stats功能。

CADVISOR

https://github.com/google/cadvisor

cAdvisor是一个开源项目，好比 Docker stats向用户提供关于运行容器的资源使用信息。cAdvisor最初是由谷歌开发的，用于管理其lmctfy容器，但它现在也支持Docker。作为守护进程，它收集、聚集、处理和导出关于运行容器的信息。

 

cAdvisor有一个web界面，可以生成多个图表，但是像Docker stats一样，它只监控一个Docker主机。它可以作为容器安装在Docker machine上，也可以在Docker主机本身上安装。

 

cAdvisor本身只保留60秒的信息。需要将cAdvisor设置为将数据记录到外部数据存储库中。常用于cAdvisor数据的数据存储库包括Prometheus和InfluxDB。虽然cAdvisor本身并不是一个完整的监控解决方案，但它通常是其他监控解决方案的组成部分。在Rancher版本1.2前，Rancher在Rancher agent中嵌入了cAdvisor(用于Rancher的内部使用)，但现在已经不是这样了。最新版本的Rancher使用Docker统计来收集通过Rancher UI公开的信息，因为它们可以减少开销。

 

管理员可以轻松地在Rancher上部署cAdvisor，它是几个综合监控堆栈的一部分，但是cAdvisor不再是Rancher本身的一部分。

SCOUT

http://scoutapp.com

Scout是一家总部位于科罗拉多州的公司，它提供基于云的应用程序和数据库监控服务，主要针对Ruby和Elixir环境。其现有的监控和警报架构使其能够监控Docker容器。

 

我们提到Scout，因为之前在比较监控Docker的解决方案时就提到了它。通过灵活的告警和与第三方告警服务的集成，Scout提供全面的数据收集、过滤和监控功能。

 

Scout的团队提供了如何使用Ruby和StatsD编写脚本的指导，以利用Docker Stats API、Docker Event API和传递数据来监控这些脚本。他们还打包了一个Docker - scout容器，可以在Docker Hub(scoutapp / Docker - scout)上使用，这就使安装和配置scout代理变得更简单。易用性取决于用户是自行配置StatsD代理，还是使用打包的docker-scout容器。

 

作为一种托管云服务，ScoutApp可以在快速启动并运行容器监控解决方案时省去许多麻烦。如果您正在部署Ruby应用程序或运行Scout支持的数据库环境，使用Scout解决方案，可以帮助您很好地整合您的Docker、应用程序和数据库级别的监控。

 

但是，用户可能需要注意一些事项。在大多数服务级别上，该平台只允许保留30天的数据，而不是每个被监控的主机。至于价格，每月定价的标准套餐价格从99美元到299美元不等。这一开箱即用的解决方案只能提取和传递有限的指标，也不太适用于Kubernetes相关的监控。此外，虽然docker-scout在Docker Hub上可用，但开发是由Pingdom完成的，在过去的两年中，Scout的代理组件只有很小的更新。

 

Rancher自身并不默认原生支持Scout，但由于Scout是云服务，所以它在Rancher中很容易部署和使用，特别是当使用基于容器的代理时。目前，docker-scout代理不在Rancher应用程序目录中。

PINGDOM

http://pingdom.com

上文中我们提到Scout作为云托管的应用程序，因此还需要提到一个类似的解决方案，称为Pingdom。Pingdom是由德克萨斯州奥斯汀市的SolarWinds公司运营的托管云服务，它是一家专注于监控IT基础架构的公司。Pingdom的主要用例是网站监控，作为服务器监控平台的一部分，Pingdom提供了大约90个插件。事实上，Pingdom维护docker-scout，同样地，Scout也使用 StatsD代理。

 

Pingdom值得关注的原因在于，它灵活的定价方案似乎更适合监控Docker环境。用户可以根据计划收集到的StatsD数据数（每10个数据每月要价1美元）在基于每个服务器的计划之间进行选择。Pingdom易于设置和管理，对于需要一个完整的监视解决方案的用户以及希望监控容器管理平台之外的其他服务的用户而言，Pingdom非常合适。像Scout一样，Pingdom是一种云服务，并且易于同Rancher结合使用。

DATADOG

https://www.datadoghq.com/

Datadog是另一个类似于Scout和Pingdom的商业托管云监控服务。 Datadog还提供了一个Dockerized agent，用于在每个Docker主机上进行安装；然而，Datadog并没有像前面提到的云监控解决方案那样使用StatsD，而是开发了一种增强的StatsD，称为DogStatsD。Datadog代理收集并传递Docker API提供的完整数据，从而进行更详实、细致的监控。

 

虽然Datadog不能原生支持Rancher，但是Rancher UI中有Datadog目录，用户可以在Rancher上轻松地安装和配置Datadog agent。用户还可以使用Rancher 标签，Datadog中的报告反映了您在Rancher中用于主机和应用程序的标签。与前面提到的云服务相比，Datadog能够提供更好的数据访问权限和更精细的定义警报条件。与其他服务一样，Datadog也可用于监视其他服务和应用程序，并拥有超过200个集成的库。Datadog还能保留18个月的全分辨率数据，这比云服务要更长。

 

与其他云服务相比，Datadog的优势在于它具有超越Docker的集成功能，并且可以从Kubernetes、Mesos、etcd和其他在您的Rancher环境中运行的服务中收集数据。对于在Rancher上运行Kubernetes的用户来说，这种多功能性是很重要的，因为他们希望能够监控诸如Kubernetes pods、服务、名称空间和kubelet health之类的数据。Datadog-Kubernetes监控解决方案通过Kubernetes中的DaemonSets，能够自动将数据收集代理部署到每个集群节点。

 

Datadog的定价为每台主机每月约15美元，总价会根据用户需要的服务和每个主机监控的容器数量相应增加。

结   语

在下篇文章中，我们将继续对比另外五大监控方案：Sysdig、Prometheus、Heapster/GrafanaPingdom、ELK和Sensu，敬请保持关注。