容器监测环境有多种形态和大小，而监控解决方案的数量之多亦令人望而生畏。在这一系列文章中，我将对容器领域的10个监控解决方案进行全面的分析对比。
上篇文章中，我介绍了此次对比测评的方法架构，并分析了五种容器监控解决方案：原生Docker、cAdvisor、Scout、Pingdom和Datadog。本文我们将继续完成另外五种容器监控解决方案的对比：Sysdig、Prometheus、Heapster / GrafanaPingdom、ELK和Sensu。
SYSDIG
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，将其与一些产品区分开来。
PROMETHEUS
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对于那些愿意花更多精力的管理者来说是最强大的监控解决方案之一。
HEAPSTER
https://github.com/kubernetes...
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来弥补这一不足，不过Hawkular并不会自动配置为Rancher部署的一部分，而是需要用户另行操作。
ELK STACK
另一个可用于监视容器环境的开源软件栈是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进行分析：https://blog.codeship.com/mon...。在另一篇文章中，Aboullaite Mohammed描述了一个不同的用例，其重点是收集Docker日志文件，分析各种Linux和NGINX日志文件（error.log、access.log和syslog）：https://aboullaite.me/docker-...。有些商用ELK栈提供者，例如logz.io和Elastic Co，向用户提供“ELK即服务”，在原生ELK之外补充提供了告警功能。有关在Docker上使用ELK的更多信息，请访问https://elk-docker.readthedoc...。
对于希望尝试使用ELK的Rancher用户，它在Rancher Catalog中已有条目，《如何在Rancher上运行Elasticsearch》一文介绍了如何在Rancher Catalog中部署ELK。《使用容器和Elasticsearch集群对Twitter进行监控》一文介绍了如何使用ELK监控Twitter数据。尽管博洽多闻的管理员可以使用ELK进行容器监控，但与Sysdig、Prometheus或Datadog等直接针对容器监控的解决方案相比，ELK的上手和使用难度都会更大。
SENSU
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的对比方法，希望可以帮助您 “缩小列表”，针对自身需求进行更认真的评估，从而选出最适合的解决方案。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。