【IT168 评论】IT社区中大多数开发人员现在基本达成了共识：Docker是很好用的。Docker是一个开源应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，让开发者在技术上有了更大的选择自由，并且可以将微服务作为支柱以提供一种更灵活的软件构建方法，特别是在云环境中。

　　虽说公司纷纷布局Docker，但实际上，Docker操作意味着增加了复杂性，因为其有着丰富的基础设施和应用程序数据，以及生产环境中附加的监控和警报等相应需求。

　　随着Docker逐渐深入开发环境，当涉及到监控容器环境时，一定要记住如下三件事情：

　　1、Docker本身并不是一个监控解决方案;

　　2、你必须知道你应该在意哪些容器指标;

　　3、收集应用程序指标有很多选择。

　　接下来，我们来深入聊聊Docker容器监控方面的问题。

　　围绕着容器价值和重要性，很多IT从业人员经常会提出一个看似很合逻辑的问题“在我的生产环境中怎么监控Docker?”你可能认为监控Docker守护进程，Kubernetes或者Mesos调度程序并不是特别复杂，因为这些都有相应的解决方案。在Docker容器中运行应用程序只需要更改应用程序的打包，调度、编排以及如何运行。但这个问题的正确问法应该是“如何根据Docker的改变来变化应用程序的监控方式?”这个问题的答案是“视情况而定”。

　　主要是由应用程序的环境、用例和目标依赖性所决定的。所使用的编排技术，Docker镜像理念以及容器应用程序提供的可观察性级别和其他很多考虑因素都会影响具体的监控方式。

　　要开始了解微服务架构方案和Docker环境将如何影响监控策略，就要问自己四个问题。（注意，不同的应用程序有不同的答案，监控方法也会反映出不同。）

　　1、你想要跟踪特定的应用程序指标还是仅跟踪系统级指标?

　　2、你的应用程序是静态的还是动态的(即，运行中哪些位置是静态映射，哪些位置是动态映射，是调度还是打包)?

　　3、如果你有应用程序的特定指标，你是从应用程序内轮询这些指标，还是将它们推送到某个外部端点?如果你轮询这些指标，它们是否会通过你容易暴露在容器中的TCP端口?

　　4、你运行的是轻量级、单线程Docker容器还是重量级的?

　　获取容器指标

　　当从容器中收集系统级指标时，Docker会全部覆盖到。Docker守护程序已经通过Docker远程API的/ stats端点公开了可用于运行容器的CPU，内存，网络和I / O使用的详细指标。不管你是否计划收集应用程序级别的指标，你都应该首先从容器中获取度量标准。从所有容器中收集指标最简单和最可靠的方法是在每个具有Docker守护程序以及docker-collectd插件的主机上运行collectd。

　　TypesDB “/usr/share/collectd/docker-collectd-plugin/dockerplugin.db”

　　LoadPlugin python

　　<Plugin python>

　　ModulePath “/usr/share/collectd/docker-collectd-plugin”

　　Import “dockerplugin”

　　<Module dockerplugin>

　　BaseURL “unix://var/run/docker.sock”

　　Timeout 3

　　</Module>

　　</Plugin>

　　如果你正在使用Docker Swarm，Swarm API端点将暴露出完整的Docker远程API，即在集群中执行所有容器的报告数据。 这意味着你只需要一个带有docker-collectd 插件的collectd实例来指向Swarm管理器的API端点就可以了。

　　TypesDB “/usr/share/collectd/docker-collectd-plugin/dockerplugin.db”

　　LoadPlugin python

　　<Plugin python>

　　ModulePath “/usr/share/collectd/docker-collectd-plugin”

　　Import “dockerplugin”

　　<Module dockerplugin>

　　BaseURL “tcp://swarm-manager:3376”

　　Timeout 3

　　</Module>

　　</Plugin>

　　一旦所有的容器度量标准都流入监控系统，就可以构建图表和仪表板，进而可视化容器和基础架构的性能了。某些监控系统甚至可以自动发现这些指标，并提供内置仪表板，以显示从集群到主机到容器的Docker基础架构。

　　收集应用程序指标

　　收集这些应用程序指标更复杂，如果你的应用程序不自动推送指标到远程端点，你将需要知道应用程序运行在哪里，要轮询什么指标，以及如何从应用程序内轮询这些指标。

　　如果不是第三方软件，我强烈建议你设置应用程序自行报告其度量标准。 事实上，大多数代码工具库应该早就存在这种方式了，或者，应该很容易地就可以将此功能添加到代码库，但要确保远程端点容易(如果可能的话)动态配置。

　　收集第三方软件的应用程序指标可能会非常棘手，因为大多数时候，你要监控的应用程序不能将度量标准数据推送到外部端点。因此，你必须直接从应用程序，JMX或者日志中轮询这些指标。在Dockerized环境中，这使得配置监控系统非常有挑战性，这取决于使用的动态容器调度形式。

　　静态容器放置

　　无论是按配置还是按惯例，都知道应用程序容器的位置，都可以更容易地收集这些应用程序的度量标准。收集过程一开始就像从中心位置或每个主机的优先位置上配置collectd一样简单。请记住，你可能必须公开其他TCP端口才能暴露应用程序度量标准的端点。在某些情况下，例如Elasticsearch和Zookeeper，API的特定端点是直接可用的，而在其他情况下，例如使用Kafka，你需要启用和公开JMX。

　　动态容器调度

　　动态容器调度程序(如Kubernetes和Mesos/Marathon)通常不会控制应用程序执行的位置。因此，即便你发现了应用程序，也很难弥合指标收集和监控系统之间的差距。使用无服务器的基础架构或纯容器托管提供商提都有类似的挑战。这个问题有三个解决方案，但没有一个是完美的，但每个都提供了从基于容器的应用程序收集指标的起点。

　　当你的容器调度程序开始工作，找到一种方法使你的指标收集系统可动态重新配置。记住构建一个侦听由容器调度程序生成事件的服务，当新容器开始并对将要到来的容器做出反应时，为了重新配置你的指标收集系统，需要做大量的工作。例如，如果你使用collectd，这可能意味着需要自动重新生成其配置节并根据需要重新启动。

　　在“sidekick”容器中运行collectd，并使用容器调度程序生成的事件自动启动和停止这些sidekicks。对于环境中运行的每个应用程序容器，将启动collectd(使用最少的配置)，以便从相应容器的应用程序中收集指标。显然，此方法会增加运行的容器数量，但提供的指标收集过程更具灵活性和可靠性。 尽可能通过执行使用放置约束的sidekick容器最小化网络参与，这将强制它与应用程序容器在相同的物理主机上运行。

　　应用程序启动时，collectd开始报告应用程序的度量标准。最小配置可以在localhost上定制和运行，在这种情况下，你需要自己管理应用程序运行的生命周期。

　　使用SignalFx监控Docker

　　自2013年以来，就有组织一直在SignalFx上运行Docker容器。我们管理的每个应用程序实际上都在Docker容器中执行。在此过程中，可以学到如何监控基于Docker的基础架构，以及如何获得对应用程序的最大可见性，无论它们在何处运行。

　　这些容器的执行主机都属于特定的服务或角色。Salt是一个配置管理系统，可以在每个主机上设置和配置collectd。与对客户的建议一样，我们使用collected：使用SignalFx collectd包，SignalFx collectd元数据插件和Dockercollectd插件。

　　通过这种设置，我们可以从运行的每个AWS实例到每个应用程序实例获得基础架构所有层的完全可见性。我们的第一方应用程序的度量标准直接推送到SignalFx中，而来自第三方应用程序的指标通过这些应用程序的相应插件提供。

　　虽然应用程序指标是应用程序运行状况最主要和清楚的信息来源，但它也有助于监视一些系统级指标。当将多个容器包装在同一主机上时，由docker-collectd插件报告的容器指标可以帮助我们设置有意义的警报和异常检测机制，以补充我们应用程序级的异常检测。

　　根据我们的经验，CPU和网络利用率是容器的关键指标，一旦他们接近100%，就会引起我们的密切关注。通过使用警报来识别有问题的容器和应用程序，我们可以在应用程序失败之前修复这些问题。当然，内存利用率也是一个很有用的指标。

　　监控即服务

　　SignalFx团队以前在Facebook上构建了分析系统，每天监控超过22万亿个指标。SignalFx通过强大的流分析功能在分布式服务上聚合指标，实时提醒服务层问题和趋势，之后与主机特定的错误进行比较。因此，它解决了传统监控，APM和日志解决方案未解决的关键应用和基础架构管理挑战。

　　SignalFx通过提供以下功能帮助各种规模的运营和产品团队管理其生产环境：

　　1、实时分析。使用SignalFx，你可以通过应用程序运行环境的指标流进行计算，并深入查看事件是否正常，预测发展趋势或存在的威胁。

　　2、可操作警报。针对你选择的指标获取提醒，并仅针对可用性和相关效果更改设置检测器。

　　3、监控即服务。基于云的监控解决方案为任何规模的操作提供了灵活性。由于硬件或维护要求没有限制，扩展配置是自动的。

　　4、广泛集成。提供完整的目录，包括已配置的插件，内置仪表板，以及发送指标的开放式方法，随着基础设施的发展而增加监控工作负载。

　　5、即时洞察每个用户。SignalFx对高级用户来说是足够先进的，足以监测产品生命周期的每个阶段。

　　随着Docker的不断发展，它提出了关于现代监控状态的重要观点。随着容器的兴起，开发和运营团队面临几个新的挑战。首先，必须适应大小和种类不断变化的数据，这些数据可能由各种系统生成。其次，我们必须满足用户在监控解决方案和操作上的广泛诉求。

　　幸运的是，开始监控Docker应用程序比你想象的要容易，只要你知道你所面临的问题不是“我如何监控Docker?”而是“如何根据Docker的改变来变化监控环境和应用程序的方式?”