【编者的话】本文对容器的可视化做了一些研究与探讨，揭示了容器资源指标监控的重要性。
据说仅仅在过去一年里Docker的使用量就翻了一倍，那么对容器监控的需求越来越急迫也在情理之中。虽然使用容器带来了很多好处，但是它在帮助我们简化很多工作的同时也带了额外的粒度和依赖性管理。这就是为什么可视化运行态容器很重要的原因。
更令人惊讶的是，直到目前为止，仍然没有用来监控Docker容器资源指标的直观方法。
Docker 1.5中引入的Docker Stats API带来了从容器中输出资源指标（CPU和内存使用量）的能力。而且也有很多开源的项目致力于容器的监控，这其中就包括Google的
cAdvisor也提供存储相关的资源指标，但是当你有挂载的数据卷的时候，监控起来就很困难。
在迁移后很短的时间内，我们给这个应用加了一些Twitter的账户。这让它每秒处理的tweets增加到超过8个，有40倍的增长。毫无意外地，这样地增长给资源用来带来了很大的影响。
只要运行cAdvisor就可以得到这些信息，无需其他操作。如果你用容器隔离应用，你可以很明显地从CPU、内存和吞吐量看出你的改变带来的影响。在这里我们只看了CPU，但是其他的资源指标都展现了类似的行为。
上面的图表表明CPU使用量和Tweet处理量是线性相关的。通过这条线，我们可以预测在CPU使用量达到100%之前，这个服务器能够处理的tweets上限。
以前，发现数据之间的关系意味着手头要有比较准确的统计数字，甚至一些代码。在Wavefront里，只需要点两下鼠标就可以了。
cAdvisor。从cAdvisor这个项目的GitHub上可以了解到cAdvisor这个工具是：
一个收集、聚合、处理以及导出运行态容器相关信息的后台进程。它为每个容器保留了隔离资源的参数、历史资源使用量、所有历史资源用量的矩形图以及网络统计。这些数据是由容器以及服务器导出的。
运行cAdvisor
cAdvisor最棒的一点在于它运行起来非常简单。因为它本身就是运行在容器里，所以你可以像运行其他任何容器一样把它运行起来，运行的结果是可预知并且始终一致的。它也可以和一些在容器外的storage driver打包使用。当你指定了storage driver参数的时候，它会自动把资源指标导出到对应的storage driver上。比如，下面的命令会在任意一个Docker主机上创建一个cAdvisor实例，然后把资源指标导出到一个StatsD服务器上：
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
-storage_driver=statsd
-storage_driver_host=your_statsd_host:8125
-storage_driver_db=docker001
在Wavefront中查看容器指标
最近，我们把之前用来做演示的服务以及相关功能整合到新的服务器上。当我们开始做这件事时，我们想要用Docker重新部署。通过把每个服务隔离在容器中，我们可以简化部署和扩展的流程。我们也能够用cAdvisor隔离每个容器的资源指标。当你在同一个主机上运行多个容器的时候，这就特别有用，和我们的情况一样。 通过上面的命令，cAdvisor就可以立即输出指标到StatsD服务器上。这些指标已下面的命令格式创建：stats.gauges...Storage_driver_db是你的Docker主机传送给cAdvisor的任意一个名字。在这个案例里，我们使用了
docker001：
对比容器资源使用量
我们迁移的其中一个服务是Twitter流处理应用。这个Twitter流处理应用（下图中的“twittermentionstream”）只从少量support账户处理tweets。在Twitter流量高峰时间段时，它处理的tweets每秒也不到0.2个。但是，它在我们的容器中仍然是消耗CPU最多的：
用容器指标规划产能
举个例子，当我们想给这个流处理应用增加更多Twitter账户时，我们可以从上面的图表里面知道这个应用每秒处理8个tweets时使用了服务器将近40%的CPU。因此，我们会想要评估一下CPU使用量和Tweet处理量之前的相关性。
