轻量级虚拟化容器 Docker，自发布以来便广受业界关注，在开源界和企业界掀起了一阵风。Docker 容器相对于 VM 有以下几个优势：启动速度快；资源利用率高；性能开销小。
从图中可以看出 Docker 和 虚拟机的差异，虚拟机的 Guest OS 和 Hypervisor 层在 Docker 中被 Docker Engine 层所替代，Docker 有着比虚拟机更少的抽象层。由于 Docker 不需要通过 Hypervisor 层实现硬件资源虚拟化，运行在 Docker 容器上的程序直接使用实际物理机的硬件资源。因此在 CPU、内存利用率上 Docker 略胜一筹。Docker利用的是宿主机的内核，而不需要 Guest OS，因此，当新建一个容器时，Docker 不需要和虚拟机一样重新加载一个操作系统内核，因此新建一个 Docker 容器只需要几秒钟。
既然 Docker 这么火，那么问题来了，为了能够更精确的分配每个容器能使用的资源，我们想要实时获取容器运行时使用资源的情况，怎样对 Docker 上的应用进行监控呢？Docker 的结构会不会加大监控难度？
我们都了解， container 相当于小型 host，可以说存在于 hosts 与应用之间的监控盲区，无论是传统的基础组件监控还是应用性能监控的方式，都很难有效地监控 Docker。了解了一下现有的 Docker 相关监测 App 和服务，包括简单的开源工具和复杂的企业整体解决方案，下面列举几种Docker 监控工具作为参考：
1. cAdvisor
谷歌的 container introspection 解决方案是 cAdvisor，这是一个 Docker 容器内封装的实用工具，能够搜集、集料、处理和导出运行中的容器的信息。通过它可以看到 CPU 的使用率、内存使用率、网络吞吐量以及磁盘空间利用率。然后，你可以通过点击在网页顶部的 Docker Containers 链接，然后选择某个容器来详细了解它的使用情况。cAdvisor 部署和使用简单，但它只可以监视在同一个 host 上运行的容器，对多节点部署不是太管用。
2. Cloud Insight
在我们列举的几个监控 Docker 的服务或平台中，这是唯一一款国内产品。Cloud Insight 支持多种操作系统、云主机、数据库和中间件的监控，原理是在平台服务仪表盘和自定义仪表盘中，采集并处理 Metric，对数据进行聚合与分组等计算，提供曲线图、柱状图等多样化的展现形式。优点是监控的指标很全，简单易用，但目前正式版还未上线，可以期待一下。
3. Scout
Scout 是一款监视服务，并不是一个独立的开源项目。它有大量的插件，除了 Docker 信息还可以吸收其他有关部署的数据。因此 Scout 算是一站式监控系统，无需对系统的各种资源来安装各种不同的监控系统。 Scout 的一个缺点是，它不显示有关每个主机上单独容器的详细信息。此外，每个监控的主机十美元这样略微昂贵的价格也是是否选择 Scout 作为监控服务的一个考虑因素，如果运行一个有多台主机的超大部署，成本会比较高。
4. Sematext
Sematext 也是一款付费监控解决方案，计划收费方案是3.5美分/小时。同样也支持 Docker 监控，还包括对容器级事件的监测（停止、开始等等）和管理容器产生的日志。
时间关系我们选择了其中安装最简单的 Cloud Insight 来试验监控基于 Docker 的一个应用——Acme 的运行情况，后期时间允许会将其他几种监控方式都试一遍。
Docker 监控实战
单方面监控 Docker 可能并不太适合与业务挂钩的应用，当业务量上涨，不单单是 Docker 的负载上升，其他 JVM 指标也能也会出现上升的趋势。
我们尝试使用一个支持比较多中间件、数据库、操作系统、容器的 Cloud Insight 来说明这个实际的场景。
Cloud Insight
Cloud Insight 由于是一个 SaaS 监控方案，相对来说它的安装和部署都比较简单。在这次监控实战中，我们以 AcmeAir 为实验对象：一个可以模拟压力的电子商务类应用。
AcmeAir 是一款由原 IBM 新技术架构部资深工程师 Andrew Spyker，利用 Netflix 开源的 Netflix OSS 打造的开源电子商务应用。此应用具有如下特性：
模拟提供航班订票服务。用户可以通过移动设备或者 web 浏览器，完成新用户注册，用户登录，航班查询，订票等操作。
AcmeAir 融入了 Docker，微服务架构等理念。并采用 Tomcat、Node.js、WebSphere Application Server、WebSphere Extreme Scale、MongoDB、Cassandra 分别打造了不同版本的实现。
AcmeAir 利用 JMeter 模拟用户行为。可通过动态调整用户数量，模拟产生各种压力的事物流量。并可在应用中预先植入错误代码，模拟各种故障场景。该应用可做为压力测试，终端用户体验异常检测，故障诊断等各种测试场景的测试用例。
首先，我们要打开 Cloud Insight 监控，还好 Cloud Insight 安装简单，一条命令即可。接着，我们新建一个用于此次监控的仪表盘，依次将想要获取的指标统统添加进去。比如，选中 jvm.non_heap_memory 这个指标，选择按照 instance 分组。
我们添加以下指标：
docker.cpu.user
docker.cpu.sysytem
docker.containers.running
jvm.heap_memory
jvm.non_heap_memory
jvm.gc.cms.count
jvm.heap_memory_max
jvm.gc.parnew.time
应用 Acme 部署在四台 servers 上，我们开启四台 servers, 然后用 JMeter 给应用加压。随着时间 JMeter 不断给应用加压。
当 users 人数达到 188 时，我们再来看一下仪表盘的视图。
从图中可以看到，性能数据发生了变化，根据 JMeter 里的数据，此时 CPU 占用超过了50%，错误率也有所提升；对比来看，根据 Cloud Insight 里的曲线显示，蓝色的线所代表的 Container CPU 占用率已经超过50%，逐渐接近75%，系统剩余的 CPU 资源逐渐下降，该 Container 的系统 CPU 资源消耗也突然增大。我们可以通过这些定位到 CPU 占用率过高的 Container ，及时而主动地去了解性能瓶颈，从而优化性能，合理分配资源。
Cloud Insight 所抓取的性能指标算是较为全面，部署和展现方式都是相当简单易懂的，对这个产品可以期待一下。
Cloud Insight 集监控、管理、计算、协作、可视化于一身，帮助所有 IT 公司，减少在系统监控上的人力和时间成本投入，让运维工作更加高效、简单。想阅读更多技术文章，请访问 OneAPM 官方博客。
这篇文章作者是Usman，他是服务器和基础架构工程师，有非常丰富的分布式构建经验。该篇文章主要
分析评估了五种Docker监控工具，包括免费的和不 免费的：Docker Stats、CAdvisor、Scout、Data Dog以及Sensu。不过作者还是推荐使用Data Dog。另外还有两个工具：Prometheus与Sysdig Cloud会在下一篇做介绍分析，敬请期待。
随着Docker被大规模的部署应用，如何通过可视化的方式了解Docker环境的状态以及健康变得越来越重要。这篇文章我们来回顾下监控容器的常用工具。我会基于以下标准评估这些工具：
易于部署
信息呈现的详细度
整个部署过程中日志的聚集程度
数据报警能力
是否可以监控非Docker的资源
成本
这些评估标准可能并不全面，但是我试图强调的是最常用的工具以及优化此六项评估标准的工具。
Docker Stats命令
本文中所有使用的命令只在亚马逊EC2上的RancherOS实例中测试过。但是我想它们应该可以在任何的Docker容器中运行。
我将讨论的第一个工具是Docker本身。你可能不知道Docker客户端已经提供了基本的命令行工具来检查容器的资源消耗。想要查看容器统计信息只需运行docker stats [CONTAINER_NAME]。这样就可以查看每个容器的CPU利用率、内存的使用量以及可用内存总量。请注意，如果你没有限制容器内存，那么该命令将显示您的主机的内存总量。但它并不意味着你的每个容器都能访问那么多的内存。另外，还可以看啊都容器通过网络发送和接收的数据总量。
$ docker stats determined_shockley determined_wozniak prickly_hypatia CONTAINER CPU % MEM USAGE/LIMIT MEM % NET I/O determined_shockley 0.00% 884 KiB/1.961 GiB 0.04% 648 B/648 B determined_wozniak 0.00% 1.723 MiB/1.961 GiB 0.09% 1.266 KiB/648 B prickly_hypatia 0.00% 740 KiB/1.961 GiB 0.04% 1.898 KiB/648 B
如果想要看到更为详细的容器属性，还可以通过netcat，使用Docker远程API来查看（见下文）。发送一个HTTP GET请求/containers/[CONTAINER_NAME]，其中CONTAINER_NAME是你想要统计的容器名称。你可以从 这里看到一个容器stats请求的完整响应信息。在上述的例子中你会得到缓存、交换空间以及内存的详细信息。如果要了解什么是metrics，那么你就需要精读Docker文档的 Run Metrics部分。
评分：
1. 易于部署程度：※※※※※
2. 信息详细程度：※※※※※
3. 集成度：无
4. 生成警报的能力：无
5. 监测非Docker的资源的能力：无
6. 成本：免费
CAdvisor
我们可以使用docker stats命令和远程API来获取容器的状态信息。但是，如果你想要在图形界面中直接查看这些信息，那你就需要诸如 CAdvisor这类的工具。CAdvisor提供了早docker stats命令所显示的数据的可视化界面。运行以下Docker命令，并在浏览器里访问http://<your-hostname>:8080/可以看到CAdvisor的界面。你将看到CPU的使用率、内存使用率、网络吞吐量以及磁盘空间利用率。然后，你可以通过点击在网页顶部的Docker Containers链接，然后选择某个容器来详细了解它的使用情况。
docker run \ --volume=/:/rootfs:ro \ --volume=/var/run:/var/run:rw \ --volume=/sys:/sys:ro \ --volume=/var/lib/docker/:/var/lib/docker:ro \ --publish=8080:8080 \ --detach=true \ --name=cadvisor \ google/cadvisor:latest
CAdvisor是一个易于设置并且非常有用的工具，我们不用非要SSH到服务器才能查看资源消耗，而且它还给我们生成了图表。此外，当集群需要额外的资 源时，压力表（pressure gauges ）提供了快速预览。而且，与本文中的其他的工具不一样的是CAdvisor是免费的，并且还开源。另外，它的资源消耗也比较低。但是，它有它的局限性，它 只能监控一个Docker主机。因此，如果你是多节点的话，那就比较麻烦了，你得在所有的主机上都安装一个CAdvisor，者肯定特别不方便。值得注意 的是，如果你使用的是Kubernetes，你可以使用 heapster来 监控多节点集群。另外，在图表中的数据仅仅是时长一分钟的移动窗口，并没有方法来查看长期趋势。如果资源使用率在危险水平，它却没有生成警告的机制。如果 在Docker节点的资源消耗方面，你没有任何可视化界面，那么CAdvisor是一个不错的开端来带你步入容器监控，然而如果你打算在你的容器中运行任 何关键任务，那你就需要一个更强大的工具或者方法。
评分：（忽略了heapster，因为它仅支持Kubernetes）
1. 易于部署程度：※※※※※
2. 信息详细程度：※※
3. 集成度：※
4. 生成警报的能力：无
5. 监测非Docker的资源的能力：无
6. 成本：免费
Scout
下一个Docker监控的方法是Scout，它解决了CAdvisor的局限性。 Scout是一个应用监控服务，它能够从很多主机和容器中获得各项监测数据，并将数据呈现在有更长时间尺度的图标中。它也可以基于这些指标生成警报。要获取Scout并运行，第一步，在 scoutapp.com注册一个Scout帐户，免费的试用账号足以用来集成测试。一旦你创建了自己的帐户并登录，点击右上角的帐户名称，然后点击Account Basics来查看你的Account Key，你需要这个Key从Docker服务器来发送指标。
现在在你的主机上，创建一个名为scouts.yml的文件并将下面的文字复制到该文件中，用上边得到的Key替换到account_key。您可以对主 机指定任何有意义的变量：display_name、environment与roles等属性。当他们在scout界面上呈现时，这些将用于分离各种指 标。我假设有一组网站服务器列表正在运行Docker，它们都将采用如下图所示的变量。
# account_key is the only required value account_key: YOUR_ACCOUNT_KEY hostname: web01-host display_name: web01 environment: production roles: web
现在，你可以使用scout配置文件通过Docker-scout插件来运行scout。
docker run -d --name scout-agent \ -v /proc:/host/proc:ro \ -v /etc/mtab:/host/etc/mtab:ro \ -v /var/run/docker.sock:/host/var/run/docker.sock:ro \ -v `pwd`/scoutd.yml:/etc/scout/scoutd.yml \ -v /sys/fs/cgroup/:/host/sys/fs/cgroup/ \ --net=host --privileged \ soutapp/docker-scout
这样你查看Scout网页就能看到一个条目，其中display_name参数（web01）就是你在scoutd.yml里面指定的。
如果你点击它（web01）就会显示主机的详细信息。其中包括任何运行在你主机上的进程计数、cpu使用率以及内存利用率，值得注意的是在docker内部并没有进程的限制。
如果要添加Docker监控服务，需要单击Roles选项卡，然后选择所有服务。现在点击+插件模板按钮，接下来的Docker监视器会加载详细信息视 图。一旦详细信息呈现出来，选择安装插件来添加到您的主机。接着会给你提供一个已安装插件的名称以及需指定要监视的容器。如果该字段是空的，插件将监控主 机上所有的容器。点击完成按钮，一分钟左右你就可以在[Server Name] > Plugins中看到从Docker监控插件中获取的详细信息。该插件为每个主机显示CPU使用率、内存使用率、网络吞吐量以及容器的数量。
你点击任何一个图表，都可以拉取该指标的详细视图，该视图可以让你看到时间跨度更长的趋势。
该视图还支持过滤基于环境和服务器角色的指标。此外，你可以创建“Triggers”或警报，如果指标高于或低于配置的阈值它就给你发送电子邮件。这就允 许您设置自动警报来通知您，比如，如果你的一些容器异常关闭以及容器计数低于一定数量。您还可以设置对平均CPU利用率的警报，举例来说，如果你正在运行 的容器超过CPU利用率而发热，你会得到一个警告，当然你可以开启更多的主机到你的Docker集群。
要创建触发器，请选择顶部菜单的Roles>All Servers，然后选择plugins部分的Docker monitor。然后在屏幕的右侧的Plugin template Administration菜单里选择triggers。您现在应该看到一个选项“Add a Trigger”，它将应用到整个部署。
下面是一个触发器的例子，如果部署的容器数量低于3就会发出警报。
它的创建是为“所有的服务器”，当然你也可以用不同的角色标记你的主机使用服务器上创建的scoutd.yml文件。使用角色。你可以通过使用不同角色来 应用触发器到部署的服务器的一个子集上。例如，你可以设置一个当在你的网络的节点的容器数量低于一定数量时的警报。即使是基于角色的触发器我仍然觉得 Scout的警报系统可能做的更好。这是因为许多Docker部署具有相同主机上的多种多样的容器。在这种情况下为特定类型的容器设置触发器将是不可能的 由于角色被应用到主机上的所有容器。
比起CAdvisor，使用Scout的另一个优点是，它有 大量的插件，除了Docker信息他们可以吸收其他有关你的部署的数据。这使得Scout是你的一站式监控系统，而无需对系统的各种资源来安装各种不同的监控系统。
Scout的一个缺点是，它不显示有关每个主机上像CAdvisor的单独容器的详细信息。这是个问题，如果你在同一台服务器上运行大量的容器。 例如，如果你想有一个触发器来提醒您的Web容器的警报，但不是Jenkins容器，这时Scout就无法支持该情况。尽管有这个缺点，Scout还是一 个相当有用的工具来监控你的Docker部署。当然这要付出一些代价，每个监控的主机十美元。如果你要运行一个有多台主机的超大部署，这个代价会是个考虑 因素。
评分：
1. 易于部署程度：※※※※
2. 信息详细程度：※※
3. 集成度：※※※
4. 生成警报的能力：※※※
5. 监测非Docker的资源的能力：支持
6. 成本：每个主机$10
Data Dog
从Scout移步到另一个监控服务——DataDog，它既解决几个Scout的缺点又解除了CAdvisor的局限性。要使用DataDog，先在 https://www.datadoghq.com/注 册一个DataDog账户。一旦你登录到您的帐户，您将看到支持集成的每种类型的指令列表。从列表中选择Docker，你会得到一个Docker run命令（如下），将其复制到你的主机。该命令需要你的预先设置的API密钥，然后你可以运行该命令。大约45秒钟后您的代理将开始向DataDog系 统报告。
docker run -d --privileged --name dd-agent \ -h `hostname` \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /proc/mounts:/host/proc/mounts:ro \ -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro \ -e API_KEY=YOUR_API_KEY datadog/docker-dd-agent \
此时，容器提示你可以在DataDog Web的Events tab上处理和查看有关集群的所有动态。所有容器的启动和终止都是事件流的一部分。
您也可以点击Dashboards标签并点击创建仪表板以合计您整个群集的指标。 Datadog收集在系统中运行的所有容器的CPU使用率、内存以及I/O的指标。此外，也可以获得容器运行和停止次数以及Docker的镜像数量。 Dashboard视图可以创建任何数据的图标，或者设置整个部署、主机群、容器镜像指标的图表。例如下图显示了运行容器的数量并加以镜像类型分类，此刻 在我的集群运行了9个Ubuntu:14.04的容器。
您还可以通过主机分类同样的数据，如下图所示，7个容器在我的Rancher主机上运行，其余的在我的本地的笔记本电脑。
DataDog还支持一种称为Monitors的警报功能。DataDog的一个monitor相当于Scout的一个触发器，并允许您定义各种指标的阈 值。 比起Scout，DataDog的警报系统相当灵活与详细。下面的例子说明如何指定您监视的Ubuntu容器的终止，因此你会监视从 Ubuntu:14.04的Docker镜象所创建容器的docker.containers.running信息。
然后，特定的警报情况是，如果在我们的部署中最后5分钟有（平均）少于十个Ubuntu容器，你就会被警报。尽管这里没有显示，你会被要求填写发送出去时 的指定消息在这个警报被触发后，而且还有受到此警报的目标。在当前的例子中，我用一个简单的绝对阈值。您也可以指定一个基于增量的警报，比如是在最后五分 钟里停止的容器的平均计数是四的警报。
最后，使用Metrics Explorer选项卡可以临时聚集你的指标来帮助调试问题或者提取具体的数据信息。该视图允许您基于对容器镜像或主机绘制任何指标的图表。您可以将输出的数据组合成一个单一的图形或者通过镜像或主机的分组来生成一组图形。
DataDog相比scout在某些功能上做了显著地改善，方便使用以及用户友好的设计。然而这一级别伴随着额外的成本，因为每个DataDog agent价格为$15。
评分：
1. 易于部署程度：※※※※※
2. 信息详细程度：※※※※※
3. 集成度：※※※※※
4. 生成警报的能力：支持
5. 监测非Docker的资源的能力：※※※※※
6. 成本：每个主机$15
Sensu Monitoring Framework
Scout和Datadog提供集中监控和报警系统，然而他们都是被托管的服务，大规模部署的话成本会很突出。如果你需要一个自托管、集中指标的服务，你可以考虑 sensu open source monitoring framework。要运行Sensu服务器可以使用 hiroakis/docker-sensu-server容器。这个容器会安装sensu-server、uchiwa Web界面、Redis、rabbitmq-server以及sensu-api。不幸的是sensu不支持Docker。但是，使用插件系统，您可以配置支持容器指标以及状态检查。
在开启sensu服务容器之前，你必须定义一个可以加载到服务器中检查。创建一个名为check-docker.json的文件并添加以下内容到 此文件。这个文件告诉Sensu服务器在所有有docker标签的客户端上每十秒运行一个名为load-docker-metrics.sh的脚本。
{
"checks": {
"load_docker_metrics": {
"type": "metric",
"command": "load-docker-metrics.sh",
"subscribers": [
"docker"
],
"interval": 10
}
}
}
现在，您可以使用下面的命令通过我们的检查配置文件来运行Sensu服务器Docker容器。一旦你运行该命令，你就可以在浏览器输入http://YOUR_SERVER_IP:3000来访问uchiwa界面。
docker run -d --name sensu-server \ -p 3000:3000 \ -p 4567:4567 \ -p 5671:5671 \ -p 15672:15672 \ -v $PWD/check-docker.json:/etc/sensu/conf.d/check-docker.json \ hiroakis/docker-sensu-server
这样Sensu服务器就开启了，你就可以对每个运行有我们的Docker容器的主机上开启sensu客户端。你告诉容器将有一个名为load- docker-metrics.sh的脚本，所以让我们创建脚本，并将其放到我们的客户端容器内。创建该文件并添加如下所示的文本，将HOST_NAME 替换为您的主机的逻辑名称。下面的脚本是为运行容器、所有容器以及镜像而使用Docker远程API来拉取元数据。然后它打印出来sensu的键值标示的 值。该sensu服务器将读取标准输出并收集这些指标。这个例子只拉取这三个值，但根据需要，你可以使脚本尽可能详细。请注意，你也可以添加多个检查脚 本，如thos，只要早前在服务配置文件中你引用过它们。你也可以定义你想要检查运行Docker容器数量降至三个以下的失败。你还可以使检查通过从检查 脚本返回一个非零值失败。
#!/bin/bash
set -e
# Count all running containers
running_containers=$(echo -e "GET /containers/json HTTP/1.0\r\n" | nc -U /var/run/docker.sock \
| tail -n +5 \
| python -m json.tool \
| grep \"Id\" \
| wc -l)
# Count all containers
total_containers=$(echo -e "GET /containers/json?all=1 HTTP/1.0\r\n" | nc -U /var/run/docker.sock \
| tail -n +5 \
| python -m json.tool \
| grep \"Id\" \
| wc -l)
# Count all p_w_picpaths
total_p_w_picpaths=$(echo -e "GET /p_w_picpaths/json HTTP/1.0\r\n" | nc -U /var/run/docker.sock \
| tail -n +5 \
| python -m json.tool \
| grep \"Id\" \
| wc -l)
echo "docker.HOST_NAME.running_containers ${running_containers}"
echo "docker.HOST_NAME.total_containers ${total_containers}"
echo "docker.HOST_NAME.total_p_w_picpaths ${total_p_w_picpaths}"
if [ ${running_containers} -lt 3 ]; then
exit 1;
fi
现在你已经定义了Docker载入指标检查，那就需要使用 usman/sensu-client容 器来启动sensu客户端。您可以使用如下所示的命令启动sensu客户端。需要注意的是，容器必须以privileged来运行以便能够访问Unix sockets，它必须有Docker socket挂载以及你上面定义的load-docker-metrics.sh脚本。确保load-docker-metrics.sh脚本在你的主机 的权限标记为可执行。容器也需要将SENSU_SERVER_IP、RABIT_MQ_USER、RABIT_MQ_PASSWORD、 CLIENT_NAME以及CLIENT_IP作为参数，请指定这些参数到您设置的值。其中RABIT_MQ_USER与 RABIT_MQ_PASSWORD默认值是sensu和password。
docker run -d --name sensu-client --privileged \ -v $PWD/load-docker-metrics.sh:/etc/sensu/plugins/load-docker-metrics.sh \ -v /var/run/docker.sock:/var/run/docker.sock \ usman/sensu-client SENSU_SERVER_IP RABIT_MQ_USER RABIT_MQ_PASSWORD CLIENT_NAME CLIENT_IP
运行完此命令，一会儿你应该看到客户端计数增加1在uchiwa界面。如果您点击客户端图标，你应该看到，包括你刚才添加的客户端的客户端名单。我的客户端1是client-1以及指定的主机IP为192.168.1.1。
如果你点击客户端名称你应该得到检查的进一步细节。你可以看到load_docker_metrics检查在3月28日的10:22运行过。
如果你点击检查名称就可以看到检查运行的进一步细节。零表明没有错误，如果脚本失败（例如，如果您的Docker守护进程死掉），你会看到一个错误代码（非零）值。虽然在目前的文章中没有涉及这个，你也还可以使用 Handlers在 sensu设置这些检查失败处理程序来提醒您。此外，uchiwa只显示检查的值，而不是收集的指标。需要注意的是sensu不存储所收集的指标，它们必 须被转发到一个时间序列的数据库如InfluxDB或Graphite。这也是通过Handlers做到的。如何配置指标转发到graphite可以参考这里。
Sensu支持我们所有的评价标准，你可以对我们Docker容器和主机收集尽可能多的细节。此外，你能够聚合所有主机的值到一个地方，并对这些检查发出 警报。这些警报并没有DataDog或Scout的先进，因为你仅能够提醒单独的主机上检查失败。然而，Sensu的大缺点是部署的难度。虽然我 已经使用Docker容器自动部署许多步骤，Sensu仍然是一个需要我们安装，启动和分开维护Redis、RabitMQ、Sensu API、uchiwa与Sensu Core的复杂系统。此外，你将需要更多的工具，如Graphite来呈现指标值以及生产部署需要定制容器，今天我已经使用了一个容器为了密码的安全以及 自定义的SSL证书。除了您重?羧萜骱蟛拍芴砑痈嗟募觳椋憬坏貌恢匦缕舳疭ensu服务，因为这是它开始收集新的标准的唯一途径。由于这些原因，我 对Sensu的在易于部署的评价相当的低。
评分：
1. 易于部署程度：※
2. 信息详细程度：※※※※
3. 集成度：※※※※
4. 生成警报的能力：支持但有限
5. 监测非Docker的资源的能力：※※※※※
6. 成本：免费
总结
今天的文章涵盖了多种选项用于监控Docker容器，从免费的选择， 如Docker stats、CAdvisor或Sensu，到有偿服务，如Scout和DataDog。我的研究到目前为止DataDog似乎是用于监控Docker部 署的最好的系统。只需几秒的安装以及单行命令，所有主机都在同一个地方报告指标，在UI方面，历史趋势是显而易见的，并且Datadog支持更深层次的指 标以及报警。然而，$15一个主机系统对于大型部署是昂贵的。对于较大规模，自托管部署，Sensu是能够满足大多数的要求，不过在建立和管理一个 Sensu集群的复杂性可能让人望而却步。很显然，有很多其他的自托管的选项，如Nagios或Icinga，他们都类似Sensu。
但愿今天这篇文章会给你一些想法对于监视容器的选择。我会继续调查其他选项，包括使用CollectD、Graphite或InfluxDB与Grafana的更精简的自我管理的容器监控系统。敬请关注更多的细节。
其他信息：发布本文后，我有一些建议去评估Prometheus和Sysdig云，两个非常好的监控Docker的选择。我在这两个服务上花了一些时间，并添加了第二部分到这个文章中。你可以在 这里（译注：过后会翻译这篇）找到它。
想要了解更多关于监控和管理Docker，请参加我们的下一个Rancher在线meetup。