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

容器监测环境有多种形态和大小。有些是开源的，而另外一些则是商业性质的。有些能够借助平台一键部署（例如在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，敬请保持关注。