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

容器监测环境有多种形态和大小。有些是开源的，而另一些则是商业性质的。有些可以借助平台一键部署（例如在 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 个监控解决方案如何对应我们在上文提出的七层对比模型，哪些组件实现了每层功能，以及组件的所在位置。每个框架都是极其复杂的，下图的对比方式毋庸置疑是一种简化，不过它也会给大家提供一个有用的视角来了解各个组件的功能。

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

每个解决方案的深入研究

1 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 功能。

2 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 本身的一部分。

3 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 应用程序目录中。

4 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 结合使用。

5 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，敬请保持关注。

作者简介

Gord Sissons，加拿大多伦多咨询公司 StoryTek 的首席顾问。Gord 在 HPC、大数据和集群管理等领域拥有超过 25 年的 IT 行业经验。他毕业于安大略省渥太华的卡尔顿大学，拥有系统和计算机工程学位。