本文翻译自：Monitoring is key to Docker success in production
近期O’Reilly和Ruxit进行了一项关于容器和Docker生态系统的调查。调查的目标是了解这种技术在整个生命周期的应用情况。除了提供一些令人吃惊的关于Docker的统计数据，这个调查指出了一些早期Docker使用者面临的挑战。
Docker是未来的交付栈。
Docker或相关容器技术越来越多采用到生产环境。大多数的被采访者已经使用Docker，另外一部分决定未来12个月将采用Docker技术提上日程。云平台对于Docker的支持也在飞速增长，例如AWS宣布了他们增强的容器服务，像OpenStack等主要云技术站将对Docker的支持作为软件交付的关键技术。如果你还没有使用Docker，是时候来一探究竟了。
生产环境有别于其他环境
像其他创新技术，人们开始使用Docker在一个小的、可控的环境。所以不要惊讶Docker为什么在开发环境使用如此广泛。技术先锋和行业领袖早已跨越了这个阶段。一旦你熟悉了Docker简单、无缝的应用交付过程，将它继续应用到你的生产环境是件很自然的事。
一旦人们将Docker应用于生产环境，他们会认识到实际的变化不仅仅是容器技术本身。最大的变化来自于对于一个新的应用交付系统的全程控制和管理。
掌握快速演进的工具链是关键
自动化是高效交付微服务的功能的关键。在基本的Docker环境中，持续集成和持续部署过程要求能适配他们支持推送或拉取的注册镜像。通常构建服务器（例如：Jenkis）或配置管理工具（例：Ansible）是由Docker集成，以便于生成和传送Docker生产镜像。
专用Docker自动化技术发展非常迅速，每个新版本发布都会引入众多的新功能和改进。这些工具包括打包、部署和容器操作，典型的Docker工具，诸如Compose and Swarm，另外也包括第三方工具Wercker，Kubernetes，Meesos上层的Mesosphere’s Marathon。
保证这些工具链正常工作将是一个挑战。因此使用这种高度自动化工具链导致了功能的快速发展也造成大多公司缺乏长期的经验。
监控证明了它的特殊价值，它可以跟踪工具之间的通信并验证自动化过程的结果。利用这种方式，监控可以区别生产环境中工具配置的不一致和缺陷。应用监控是确认是否自动化流程链产生了可交付的应用程序的预期效果的关键。
“自驱动”的容器架构还没有实现
采用容器技术的一个重要原因是能够帮助你从笨重的整体应用架构迁移到轻便，灵活的微服务。Docker是完美的封装，传输，并在多个主机上运行的小而可扩展的微服务。
小规模的部署使架构富于细粒度，可动态扩展。众多的微服务，业务流程工具的不可或缺，因此这些环境有更多的可控性。
像Mesos/Marathon,AWS ECS,还有Kubernetes在处理容器托管微服务之间的协调和通信是特别有效的。它们更容易部署，并通过添加主机的容器簇和注册负载平衡的容器扩展环境。这些工具甚至可以处理故障转移和容器损坏的重新部署，以保持服务所需的容器数量。
尽管所有这些功能，一些关键业务挑战的解决方案仍处于早期阶段。简单地说，这些工具支持你扩展业务，但它们需要输入以确定何时以及怎样的具体业务进行调整。此信息通常可以从应用程序监控获得，因为它提供服务深层，实时的分析。这包括与其他服务的入站和出站服务的通信。
高质量的性能数据的关键是确定添加和删除容器的响应时间和性能在每个服务中的影响。其结果是，监控工具现在是流程工具的反馈环路的一部分。监控工具驱动业务流程配置的调整（例：当要减少或增加容器的数量）。
管理和监控必须演进
高度动态和可扩展的微服务环境需要监控其扩展。在2014年Monitorama谈话，Adrian Cockroft说，监控系统本身需要比他们监控的系统有高的可用性和可扩展性。他是对的。
监控需要自适应不断变化的环境配置。手动配置像手动部署和协调一样是不切实际的。自动发现和自学习的性能基准，以及高动态仪表板功能，使很多传统监控解决方案变得过时。
由于这些环境的动态扩展，监控解决方案需要跟他们保持一致。这使得基于SaaS的解决方案成为监控Docker环境的理想人选。即使SaaS不是一个备选，由Ruxit提供的“类SaaS”的企业级服务将是首选方案。
创新需要监控Docker环境
如果在生产中部署Docker及相关容器技术，监控是对于了解和确认你的服务是否工作正常是非常关键的。不断增长的Docker相关工具和项目用于提供分布式应用的基本基础架构，创建了一组全新的监控需求，它远远超出传统的指标的驱动方案。动态和可扩展性的要求需要一套新的监控工具，改造传统监控工具不能提供创新以应对这些环境的关键挑战。
