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

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

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

  • 原生 Docker
  • cAdvisor
  • Scout
  • Pingdom
  • Datadog
  • Sysdig
  • Prometheus
  • Heapster / GrafanaPingdom
  • ELK
  • Sensu

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

对比架构

客观地对比监控解决方案面临的一个挑战是：解决方案的架构、功能、部署模型和成本可能会有很大的差异。

一个解决方案可以从单个主机提取和绘制 Docker 相关的数据，而另一个解决方案则可以从许多主机收集数据，测量应用程序响应时间，并在特定条件下发送自动警报。

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

  • 主机代理——主机代理代表监控解决方案的「肢体」，它会从各种来源（如 API 和日志文件）提取时间序列数据。主机代理通常安装在每个集群主机上（无论是本地还是云端），并且它们通常被打包成 Docker 容器，以便部署和管理。
  • 数据收集架构——虽然单主机数据有时很有用，但管理员可能需要所有主机和应用程序的统一视图。监控解决方案通常具备一些机制来收集每个主机的数据，并将其保存在共享数据存储区中。
  • 数据存储——数据存储可能是传统的资料库，但更常见的一种形式是可伸缩的分散式资料库，由键值对组成的时间序列数据进行了优化。有些解决方案具有原生数据存储，而其他解决方案则使用的是开源的数据存储插件。
  • 聚合引擎——要存储来自数十个主机的原始数据，可能遇见的一大问题是数据量会变得过大。监控架构通常提供数据聚合功能，定期将原始数据转换为统一的度量标准(比如每小时或每日进行汇总)，清除不再需要的旧数据，或以某种方式重新分解数据，以支持预期的查询和分析。
  • 过滤和分析——一个监控解决方案就像是你从数据中获得的洞察力。不同的监控解决方案之间，筛选和分析的能力常常差别很大。有些解决方案仅支持以简单的时间序列图表的形式来进行一些预先打包的查询, 而另一些则具有可自定义的仪表板、嵌入式查询语言和复杂的分析功能。
  • 可视化层——监控工具通常具有可视化层，用户可以在其中与 Web 界面进行交互以生成图表、制定查询以及在某些情况下定义警报条件。可视化层可能与筛选和分析功能紧密耦合, 也可能根据解决方案而与其分开。
  • 告警和通知——很少管理员有时间整天坐著、时刻关注监控图表。监控系统的另一个常见特性是告警子系统，如果达到或超过了预定义的阈值，可以向管理员发出通知。

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

  • 解决方案的完整性
  • 是否易于安装和配置
  • 关于 Web 用户界面的详细信息
  • 是否能够将警报转发至外部服务
  • 社区支持和参与程度（若该方案为开源项目）
  • Rancher 应用程序目录中的可用性
  • 支持监控非容器环境和应用程序
  • 原生 Kubernetes 支持（Pods、Services、Namespaces 等）
  • 可扩展性（API，其他介面）
  • 部署模式（自主托管、云上托管）
  • 成本

10 大监控解决方案的对比

下图以 High-level 的形式展示了我们提出的的 10 个监控解决方案如何对应我们在上文提出的七层对比模型，哪些组件实现了每层功能，以及组件的所在位置。

每个框架都是极其复杂的，下图的对比方式毋庸置疑是一种简化，不过它也会给大家提供一个有用的视角来了解各个组件的功能。

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

各解决方案的深入研究

1. DOCKER STATS

docker.com/docker-commu

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

github.com/google/cadvi

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

Home

上文中我们提到 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

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 美元，总价会根据用户需要的服务和每个主机监控的容器数量相应增加。

6. SYSDIG

Frontpage V4

Sysdig 是一家加州公司，为用户提供基于云计算的监控解决方案。

与前文所描述的几个基于云的监控解决方案不同的是，Sysdig更专注于监控容器环境，包括 Docker、集群、Mesos 和 Kubernetes。此外，Sysdig 还在开源项目中提供了一些可用功能，并且可以选择对 Sysdig 监控服务进行云部署还是本地部署。在这些方面，Sysdig 不同于迄今为止所出现的其他基于云的解决方案。

Sysdig 与 Datadog 类似，其目录可用于 Rancher，但 Sysdig 的本地和云安装都有单独目录。从 Rancher Catalog 里自动安装的 Sysdig 无法用于对 Kubernetes 的监控；不过，它也可以不通过 Rancher Catalog 来安装到 Rancher 之上。

商用 Sysdig 监控具有 Docker 监控、告警和故障排除功能，并且还具有 Kubernetes、Mesos 和集群识别的功能。Sysdig 能够自动识别 Kubernetes Pod 和服务，因此选择 Kubernetes 作为 Rancher 的编排架构将是一个很好的解决方案。

Sysdig 和 Datadog 一样是按每个主机每月定价。虽然 Sysdig 入门价格略高，但它每个主机上可以支持更多容器，因此根据用户的环境，实际定价可能非常相似。

Sysdig 还提供了一个全面的 CLI——csysdig，将其与一些产品区分开来。

7. PROMETHEUS

http://prometheus.io

Prometheus 是一个很受欢迎的开源监控和警报工具包，它最初是在 SoundCloud 进行构建的。现在是 CNCF 项目，也是该公司在 Kubernetes 之后的第二个托管项目。

作为一个工具包，它与目前为止所描述的其他监视解决方案有很大不同。首先一个主要的区别是，Prometheus 作为一种云服务，是模块化的，可以自行托管，这意味著无论是在本地还是在云端，用户都可以在他们的集群上部署 Prometheus。

值得注意的是，Prometheus 不是将数据推送到云服务，而是安装在每个 Docker 主机上，并通过 HTTP 从 Prometheus 提供的各种输出口获取或「抓取」数据。

其中，一些输出口被官方保留为 Prometheus GitHub 项目的一部分，而另一些则是由外部贡献。有些项目本身暴露了 Prometheus 数据，因此不需要输出口。由于 Prometheus 可高度扩展，用户需要考虑输出方的数量，并根据收集的数据量适当地配置轮询间隔。

Prometheus 的伺服器从各种来源检索时间序列数据，并将数据存储在其内部数据存储区中。此外，Prometheus 提供服务发现等功能，这是一种针对特定类型数据的独立推送网关，并且有一个嵌入的查询语言 ( PromQL )，该语言擅长查询多维数据。

同时，它也有一个嵌入式的 Web UI 和 API 。虽然 Prometheus 中的 Web UI 提供了强大的功能，但用户必须对 PromQL 十分了解，因此一些站点更愿意使用 Grafana 作为绘制和查看集群相关指标的介面。

Prometheus 有一个独立的告警管理器，它也具有独特的 UI，并且可以处理存储在 Prometheus 中的数据。和其他告警管理器一样，它可以与各种外部告警服务一起工作，包括电子邮件、Hipchat、Pagerduty、#Slack、OpsGenie、VictorOps 等。

因为 Prometheus 由许多组件组成，输出方需要根据所监控的服务进行选择和安装，所以安装起来比较困难，但是作为免费产品，在价格上 Prometheus 具有无可比拟的优势。

虽然不像 Datadog 或 Sysdig 这样精炼，但是 Prometheus 提供了类似的功能、广泛的第三方软体集成以及一流的云监控解决方案，并且 Prometheus 十分了解 Kubernetes 和其他容器管理架构。

另外，由 Infinityworks 开发的 Rancher Catalog 中的条目使得在使用 Cattle 作为 Rancher 的编排架构时，Prometheus 更容易入门，但由于配置选项的种类繁多，管理员需要花费一些时间才能正确安装和配置。

Infinityworks 提供了一些有用的插件，其中包 prometheus-rancher-exporter，这些插件将 Rancher stack 和从 Rancher API 获得的主机的健康状况发送给 Prometheus 兼容端点。因此，Prometheus 对于那些愿意花更多精力的管理者来说是最强大的监控解决方案之一。

8. HEAPSTER

github.com/kubernetes/h

Heapster 是 Kubernetes 旗下的一个项目，它有助于实现容器集群监控和性能分析。此外，Heapster 对 Kubernetes 和 OpenShift 的支持十分良好，也很适用于在 Rancher 上使用 Kuberenetes 作为编排工具的用户。Cattle 或者 Swarm 的用户则通常不会选择它。

人们经常将 Heapster 定义为一个监控解决方案，但更确切地说，它应该是一个「集群范围内的监控和事件数据聚合器」。Heapster 从来不单独部署，相反，它是一堆开源组件的一部分。Heapster 监控堆栈通常由以下部分组成：

  • 数据收集层：例如，在每个集群主机上使用 Kubelet 访问的 cAdvisor
  • 可插入式存储后端：例如，ElasticSearch、InfluxDB、Kafka、Graphite 等
  • 数据可视化组件：Grafana 或 Google Cloud Monitoring

Heapster 与 InfluxDB、Grafana 共同组成了一个流行的堆栈，当用户在 Rancher 上部署 Kubernetes 时，此组合便会默认安装在 Rancher上。

需要注意的是，这些组件被认为是 Kubernetes 的附加组件，因此它们可能不会被自动部署到所有 Kubernetes 发行版中。

InfluxDB 受欢迎的其中一个原因是，它是少数几个支持 Kubernetes 项目和数据的数据后端之一，并且可以对 Kubernetes 进行更全面的监控。

值得注意的是，Heapster 本身不支持在商用云的解决方案或 Prometheus 中发现的与应用程序性能管理（APM）相关的告警或服务。需要监控服务的用户可以使用 Hawkular 来弥补这一不足，不过 Hawkula 并不会自动配置为 Rancher 部署的一部分，而是需要用户另行操作。

9. ELK STACK

elastic.co/

另一个可用于监视容器环境的开源软体栈是 ELK，由 Elastic 提供的三个开源项目组成。

ELK 是通用的，广泛用于各种分析应用程序，日志文件监控是其中关键的一环。ELK 以其关键组件的首字母命名:

  • Elasticsearch：基于 Lucene 的分散式搜索引擎
  • Logstash：一个数据处理管道，用于获取数据并将其发送到 Elastisearch（或其他「托盘」）
  • Kibana：Elasticsearch 的可视化搜索仪表板和分析工具

Elastic 栈中一个容易被忽视的成员是 Beats，项目开发人员将其描述为「轻量级数据托运器」。现在有许多现成的 Beats 托运器，包括 Filebeat（用于日志文件）、Metricbeat（用于收集各种来源的数据）以及用于简单的 uptime 监控等。

ELK 栈的部署方式有所不同。Kiratech 的 Lorenzo Fontana 在这篇文章中解释了如何使用 cAdvisor 从 Docker Swarm 主机收集数据以存储在 ElasticSearch 中，并使用 Kibana 进行分析：blog.codeship.com/moni…isor/ 。

在另一篇文章中，Aboullaite Mohammed 描述了一个不同的用例，其重点是收集 Docker 日志文件，分析各种 Linux 和 NGINX 日志文件（error.log、access.log 和 syslog）：aboullaite.me/docker-m…tack/ 。

有些商用 ELK 栈提供者，例如 logz.io 和 Elastic Co，向用户提供「ELK 即服务」，在原生 ELK 之外补充提供了告警功能。有关在 Docker 上使用 ELK 的更多信息，请访问：elk-docker.readthedocs.io 。

对于希望尝试使用 ELK 的 Rancher 用户，它在 Rancher Catalog 中已有条目：

《如何在 Rancher上运行Elasticsearch》一文介绍了如何在 Rancher Catalog 中部署 ELK 。

《使用容器和 Elasticsearch 集群对 Twitter 进行监控》一文介绍了如何使用 ELK 监控 Twitter 数据。

尽管博洽多闻的管理员可以使用 ELK 进行容器监控，但与 Sysdig、Prometheus 或 Datadog 等直接针对容器监控的解决方案相比，ELK 的上手和使用难度都会更大。

10. SENSU

elastic.co/

Sensu 是一个通用的自主监控解决方案，支持多种监控应用。用户可在 MIT 许可下获得一个免费的 Sensu Core 版本，Sensu 的企业版则拥有更多的附加功能，价格为每月 99 美元，可以为 50 个 Sensu 客户端提供服务。

Sensu 使用术语「客户端」来指代其监控代理，因此根据您监控的主机和应用程序环境的数量，企业版可能会变得非常昂贵。Sensu 在容器管理之外还拥有非常强大的功能，但就监控容器环境和容器化应用程序这方面来看，它与其他平台并无差别。

Sensu 插件的数量持续增长，现在已有数十个 Sensu 和社区支持的插件可以从各种来源提取数据。2015 年 Rancher 对 Sensu 进行早期评估时，那时 Sensu 用户要从 Docker 中提取信息，需要开发 shell 脚本。但是现在，Sensu 已经有了一个不错的 Docker 插件，这使得 Sensu 更易于使用了。

插件往往是用 Ruby 编写的，使用基于 gem 的安装脚本，这些脚本需要在 Docker 主机上运行。用户可以在他们选择的语言中开发额外的插件。与我们讨论过的其他监控解决方案相同的是，Sensu 插件不是部署在自身容器中。(这一点毫无疑问，因为 Sensu 并非在监控容器的基础上构建的。)

由于不同的用户希望根据自己的监控要求混合和匹配插件，因此为每个插件设置单独的容器将会非常棘手，这可能是为什么不使用容器进行部署的原因。

不过，插件可以使用 Chef、Puppet 和 Ansible 等平台进行部署。例如，对于 Docker 来说，有 6 个独立的插件可以从各种来源收集与 Docker 相关的数据，包括 Docker 统计信息、容器数量、容器运行状况、Docker ps 等等。

Sensu 插件的数量非常多，包括许多用户可能在容器环境（ElasticSearch、Solr、Redis、MongoDB、RabbitMQ、Graphite 和 Logstash 等）中运行的应用程序栈。

此外，Sensu 还提供用于管理和编排架构的插件，如 AWS 服务（EC2、RDS、ELB）。但是在插件列表中，Kubernetes 似乎消失了。但是 Sensu 提供对 OpenStack 和 Mesos 的支持。

Sensu 通过 RabbitMQ 使用消息汇流排，以协助代理/客户端与 Sensu 伺服器之间的通信。Sensu 用 Redis 存储数据，但它的设计目的是将数据路由到外部的时间序列资料库。支持的资料库包括 Graphite、Librato 和 InfluxDB。

安装和配置 Sensu 需要花点功夫。安装 Sensu 前必须先安装 Redis 和 RabbitMQ。 Sensu 伺服器、Sensu 客户端和 Sensu 仪表板需要单独安装，并且根据部署的是 Sensu 内核还是企业版本，流程也会有所不同。

如前所述，Sensu 不提供容器友好的部署模型。为了方便起见，可以使用 Docker 镜像 ( hiroakis／Docker-sensu-server ) 运行 Redis、rabbitmq-server、uchiwa ( 开源 Web 层 ) 和 Sensu 伺服器组件，但在评估上，这个软体包比生产部署更有用。

Sensu 的特性非常多，但对容器用户而言，它的缺点是架构很难安装、配置和维护，因为这些组件本身没有被 Docker 化。

此外，许多告警功能（例如发送警报给诸如 PagerDuty，Slack 或 HipChat 等服务）可以在基于云的解决方案或像 Prometheus 这样的开源代码解决方案中使用，因此需要购买 Sensu 企业版许可。特别是若你使用 Kubernetes，可能 Sensu 不是最好的选择。

我们忽略的监控解决方案

Graylog 是另一个监控 Docker 的开源解决方案。和 ELK 一样，Graylog 也适用于 Docker 日志文件分析。它可以接受和解析来自多个数据源的日志和事件数据，并支持像 Beats、Fluentd 和 NXLog 这样的第三方收集器。

Nagios 通常被认为更适合于监控集群主机而不是容器，但对于那些在监控集群环境中浸淫已久的人来说，Nagios 最受欢迎。

Netsil 是一家矽谷初创公司，作为一个监控应用程序，它为 Docker、Kubernetes、Mesos 以及各种应用程序和云提供商提供插件。Netsil 的应用运营中心（AOC）与我们讨论的其它监控架构一样，以云 /SaaS 或自主托管的形式为云应用服务提供架构感知监控。

结语

容器监控解决方案很多，新的解决方案不断涌现，同时现有的解决方案不断发展。此次我们采取了 High-level 的对比方法，希望可以帮助您 「缩小列表」，针对自身需求进行更认真的评估，从而选出最适合的解决方案。

原文：rancher.com/comparing-1

推荐阅读：

相关文章