DevOps监控微服务的五原则

咱们对微服务的需求能够概括为一个词：速度。这种更快提供功能完善且可靠的软件的需求，完全改变了软件开发模式。毫无疑问，这个改变对软件管理，包括系统监控的方式，都产生了影响。在这篇文章里，咱们将重点关注放在有效地监控产品环境中的微服务所需作出的主要改变。咱们将为这一新的软件架构拟定 5 条指导性原则来调整你的监控方法。

监控是微服务控制系统的关键部分，你的软件越复杂，那么你就越难了解其性能及问题排障。鉴于软件交付发生的巨大改变，监控系统一样须要进行完全的改造，以便在微服务环境下表现更好。下面咱们将介绍监控微服务的 5 条原则，以下：

• 监控容器及其里面的东西。
• 在服务性能上作监控，而不是容器性能。
• 监控弹性和多地部署的服务。
• 监控 API。
• 将您的监控映射到您的组织结构。

利用这 5 条原则，你能够在向微服务前进的道路上，创建更有效的对微服务的监控。这些原则，可让你应对随着微服务而来的技术变化和组织变化。

微服务监控的原则

一、监控容器及其里面的东西

容器因构建微服务而凸显其重要性，容器的速度、可移植性和隔离特性让开发者很容易就爱上了微服务模型。容器的好处已经写的够多了，毋庸赘述。

容器对于其外围的系统来讲就像是黑盒子。这对于开发来讲大有裨益，从开发环境到生产环境，甚至从开发者的笔记本到云端，为它们带来高度的可移植性。可是当运行起来后，监控和解决服务问题时，这个黑盒子让常规的方法难以奏效了，咱们会想：容器里到底在运行着什么?程序和代码运行性能如何?它有什么重要的输出指标吗?从 DevOps 的视角，你须要对容器有更深的了解而不是仅仅知道有一些容器的存在。

非容器环境下衡量的典型作法，是让一个代理程序运行在主机或者虚机上的用户空间里，但这并不适用于容器。由于容器的优势是小，将各类进程分离开来，并尽量的减小依赖关系。

并且，从规模上看，成千上万的监测代理，对即便是一个中等大小的部署都是一个昂贵的资源浪费和管理的噩梦。对于容器有两个潜在的解决方案：1)要求你的开发人员直接监控他们的代码，或者2)利用一个通用的内核级的检测方法来查看主机上的全部应用程序和容器活动。这里咱们不会深刻说明，但每一种方法都有其优势和缺点。

二、 利用业务流程系统提醒服务性能

理解容器容器中的运行数据并不容易，一个单一容器相比组成一个功能或服务的容器聚合，测量复杂度要低得多。

这特别适用于应用程序级别的信息，好比哪一个请求拥有最短响应时间，或者哪些 URL 遇到最多的错误，但它一样也适用于架构级别的监测，好比哪一个服务的容器使用 CPU 资源超过了事先分配的资源数。

愈来愈多的软件部署须要一个编排系统orchestration system，将应用程序的逻辑规划转化到物理的容器中。常见的编排系统包括 Kubernetes、Mesosphere DC/OS 和 Docker Swarm。团队能够用一个编排系统来(1)定义微服务(2)理解部署的每一个服务的当前状态。你能够认为编排系统甚至比容器还重要。容器是短暂的，只有知足你的服务需求才会存在。

DevOps 团队应该将告警重点放到运行特征上，以尽量贴近监控服务的体验。若是应用受到了影响，这些告警是评估事态的第一道防线。可是得到这些告警并不容易，除非你的监控系统是基于原生于容器的。

原生容器Container-native解决方案利用编排元数据orchestration metadata来动态聚合容器和应用程序数据，并按每一个服务计算监控度量。根据您的编排工具，您可能想在不一样层次进行深刻检测。好比，在 Kubernetes 里，你一般有 Namespace、ReplicaSet、Pod 和一些其余容器。聚合这些不一样的层，对排除逻辑故障是颇有必要的，与构成服务的容器的物理部署无关。

三、 监控弹性Elastic和多地部署Multi-Location的服务

弹性服务不是一个新概念，可是它在原生容器环境中的变化速度比在虚拟环境中快的多。迅速的变化会严重影响检测系统的正常运行。

监测传统的系统常常须要根据软件部署，手动调整检查指标。这种调整能够是具体的，如定义要捕获的单个指标，或基于应用程序在一个特定的容器中的操做配置要收集的数据。在小规模上(好比几十个容器)咱们能够接受，可是再大规模就难以承受了。微服务的集中监控必须可以自由的随弹性服务而增加和缩减，无需人工干预。

好比，若是 DevOps 团队必须手动定义容器包含哪一个服务须要监控，他们毫无疑问会失手，由于 Kubernetes 或者 Mesos 天天都会按期建立新的容器。一样，若是代码发布并置于生产环境时要求运维团队安装一个定制的状态端点custom stats endpoint，也给开发者从 Docker 仓库获取基础镜像带来更多的挑战。

在生产环境中，创建面向跨越多个数据中心或多个云的复杂部署的监控，好比，若是你的服务跨越私有数据中心和 AWS，那么亚马逊的 AWS CloudWatch 就很难作到这一点。这就要求咱们创建一个跨不一样地域的监控系统，并可在动态的原生容器环境下运行。

四、 监控 API

在微服务环境中，API 接口是通用的。本质上，它们是将服务暴露给其它团队的惟一组件。事实上，API 的响应和一致性能够看做是“内部 SLA”，即便尚未定义一个正式的 SLA(服务等级协议)。

所以，API 接口的监控也是必要的。API 监控能够有不一样的形式，可是很显然它绝对不是简单的二进制上下检查。例如，了解像时间函数这样的最常使用的端点endpoint是有价值的。这使得团队能够看到服务使用的变化，不管是因为设计变动或用户的改变。

你也能够记录服务最缓慢的端点，这些可能揭示出重大的问题，或者至少指向须要在系统中作优化的区域。

最后，跟踪系统服务响应的能力是另外一个很重要的能力，它主要是开发者使用，也能帮助你了解总体用户体验，同时将信息基于底层和应用程序视角分红两大部分。

五、 将您的监控映射到您的组织结构

这篇文章着重在微服务和监控上，像其余科技文章同样，这是由于不少人都关注此层面。

对于那些熟悉康威定律Conway’s law的人来讲，系统的设计是基于开发团队的组织结构。创造更快，更敏捷的软件的压力推进了团队去思考从新调整他们的开发组织和管理它的规则。

因此，若是他们想从这个新的软件架构(微服务)上获益，他们的团队必须将微服务映射到团队自身中。也就是说，他们须要更小的更松散耦合的团队，能够选择本身的方向只要可以知足整个需求便可。在每个团队中，对于开发语言的使用，bug 的提交甚至工做职责都会有更大的控制能力。

DevOps 团队对此能够启用一个监控平台：让每个微服务团队能够有本身的警报，度量指标，和控制面板，同时也要给出总体系统的视图。

总结

让微服务流行起来的是快捷。开发组织要想更快的为客户提供更多的功能，而后微服务技术就来了，架构转向微服务而且容器的流行让快捷开发成为可能，全部相关的进程理所固然的搭上了这辆火车。

最后，基本的监控原则须要适应伴随微服务而来的技术和结构。越早认识到这种转变的开发团队，能更早更容易的适应微服务这一新的架构。

本文地址：http://www.linuxprobe.com/devops-five-rules.html