轻量级虚拟化容器 Docker,自发布以来便广受业界关注,在开源界和企业界掀起了一阵风。Docker 容器相对于 VM 有如下几个优点:启动速度快;资源利用率高;性能开销小。html
从图中能够看出 Docker 和 虚拟机的差别,虚拟机的 Guest OS 和 Hypervisor 层在 Docker 中被 Docker Engine 层所替代,Docker 有着比虚拟机更少的抽象层。因为 Docker 不须要经过 Hypervisor 层实现硬件资源虚拟化,运行在 Docker 容器上的程序直接使用实际物理机的硬件资源。所以在 CPU、内存利用率上 Docker 略胜一筹。Docker利用的是宿主机的内核,而不须要 Guest OS,所以,当新建一个容器时,Docker 不须要和虚拟机同样从新加载一个操做系统内核,所以新建一个 Docker 容器只须要几秒钟。python
既然 Docker 这么火,那么问题来了,为了可以更精确的分配每一个容器能使用的资源,咱们想要实时获取容器运行时使用资源的状况,怎样对 Docker 上的应用进行监控呢?Docker 的结构会不会加大监控难度?ios
咱们都了解, container 至关于小型 host,能够说存在于 hosts 与应用之间的监控盲区,不管是传统的基础组件监控仍是应用性能监控的方式,都很难有效地监控 Docker。了解了一下现有的 Docker 相关监测 App 和服务,包括简单的开源工具和复杂的企业总体解决方案,下面列举几种Docker 监控工具做为参考:git
1. cAdvisorgithub
谷歌的 container introspection 解决方案是 cAdvisor,这是一个 Docker 容器内封装的实用工具,可以搜集、集料、处理和导出运行中的容器的信息。经过它能够看到 CPU 的使用率、内存使用率、网络吞吐量以及磁盘空间利用率。而后,你能够经过点击在网页顶部的 Docker Containers 连接,而后选择某个容器来详细了解它的使用状况。cAdvisor 部署和使用简单,但它只能够监视在同一个 host 上运行的容器,对多节点部署不是太管用。web
2. Cloud Insightdocker
在咱们列举的几个监控 Docker 的服务或平台中,这是惟一一款国内产品。Cloud Insight 支持多种操做系统、云主机、数据库和中间件的监控,原理是在平台服务仪表盘和自定义仪表盘中,采集并处理 Metric,对数据进行聚合与分组等计算,提供曲线图、柱状图等多样化的展示形式。优势是监控的指标很全,简单易用,但目前正式版还未上线,能够期待一下。shell
3. Scout数据库
Scout 是一款监视服务,并非一个独立的开源项目。它有大量的插件,除了 Docker 信息还能够吸取其余有关部署的数据。所以 Scout 算是一站式监控系统,无需对系统的各类资源来安装各类不一样的监控系统。 Scout 的一个缺点是,它不显示有关每一个主机上单独容器的详细信息。此外,每一个监控的主机十美圆这样略微昂贵的价格也是是否选择 Scout 做为监控服务的一个考虑因素,若是运行一个有多台主机的超大部署,成本会比较高。json
4. Sematext
Sematext 也是一款付费监控解决方案,计划收费方案是3.5美分/小时。一样也支持 Docker 监控,还包括对容器级事件的监测(中止、开始等等)和管理容器产生的日志。
时间关系咱们选择了其中安装最简单的 Cloud Insight 来试验监控基于 Docker 的一个应用——Acme 的运行状况,后期时间容许会将其余几种监控方式都试一遍。
单方面监控 Docker 可能并不太适合与业务挂钩的应用,当业务量上涨,不仅仅是 Docker 的负载上升,其余 JVM 指标也能也会出现上升的趋势。
咱们尝试使用一个支持比较多中间件、数据库、操做系统、容器的 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的资源
成本
这些评估标准可能并不全面,可是我试图强调的是最经常使用的工具以及优化此六项评估标准的工具。
本文中全部使用的命令只在亚马逊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. 成本:免费
咱们可使用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是一个不错的开端来带你步入容器监控,然而若是你打算在你的容器中运行任 何关键任务,那你就须要一个更强大的工具或者方法。
1. 易于部署程度:※※※※※
2. 信息详细程度:※※
3. 集成度:※
4. 生成警报的能力:无
5. 监测非Docker的资源的能力:无
6. 成本:免费
下一个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
从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
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。