我们对微服务的需求可以用一个词来概括：速度。这种需要更快地交付功能齐全且可靠的软件的需求已经彻底改变了软件开发范式。毫无疑问，这种变化对软件管理产生了影响，包括系统的监控方式。在本文中，我们重点关注在生产环境中有效监控微服务所需的主要变化。我们将概述5条指导原则，以微调您对这种新软件架构的监控方法。监控是微服务控制系统的重要组成部分，您的软件越复杂，就越难了解其性能并解决问题。鉴于软件交付的巨大变化，监控系统也需要进行大修，以便在微服务环境中表现更好。下面我们将介绍监控微服务的5条原则，如下：监控容器及其内部的内容。监控服务性能，而不是容器性能。监控弹性和多位置服务。监控API。将您的监控映射到您的组织结构。使用这5条原则，您可以在微服务的道路上构建更有效的微服务监控。这些原则使您能够响应微服务带来的技术和组织变化。微服务监控原理1.监控容器及其内容容器之所以重要，是因为构建微服务。容器的速度、可移植性和隔离性使开发人员很容易爱上微服务模型。容器的好处上面已经写得够多了，没有必要再重复了。对于周围的系统来说，容器就像黑盒子。这对开发有很大的好处，使它们具有从开发环境到生产环境，甚至从开发人员的笔记本电脑到云端的高度可移植性。但是在运行、监控和解决业务问题时，这个黑盒子让常规的方法难以奏效。我们会想：容器中运行着什么？程序和代码运行的性能如何？它有哪些重要的产出指标？？从DevOps的角度来看，您需要对容器有更深入的了解，而不仅仅是知道某些容器的存在。在非容器环境中的典型测量方式是在主机或虚拟机的用户空间中运行一个代理，但这不适用于容器。因为容器的好处就是小，把各个进程分开，尽可能的减少依赖。而且，在规模上，监控成千上万的代理是一种昂贵的资源浪费，对于中等规模的部署来说也是一场管理噩梦。容器有两种可能的解决方案：1)要求您的开发人员直接监控他们的代码，或2)利用通用的内核级检测来查看主机上的所有应用程序和容器活动。我们不会在这里深入，但每种方法都有其优点和缺点。2、利用业务流程系统提醒服务绩效。容器中的运行数据不容易看懂。与形成功能或服务的容器聚合相比，单个容器的测量复杂性要低得多。这对于应用程序级别的信息特别有用，例如哪些请求的响应时间最短，或者哪些URL遇到的错误最多，但它对于架构级别的监控也很有用，例如哪个服务的容器使用的CPU资源比它们多已经分配了多少资源。越来越多的软件部署需要编排系统将应用程序的逻辑规划转化为物理容器。常见的编排系统包括Kubernetes、MesosphereDC/OS和DockerSwarm。团队可以使用编排系统来(1)定义微服务和(2)了解已部署的每个服务的当前状态。您可能会争辩说编排系统甚至比容器更重要。容器是短暂的，只是为了满足您的服务需求而存在。DevOps团队应将警报重点放在操作特征上，以尽可能接近监视服务的体验。如果应用程序受到威胁，这些警报是评估情况的第一道防线。但是除非您的监控系统是容器原生的，否则获得这些警报并不容易。容器原生解决方案利用编排元数据动态聚合容器和应用程序数据，并基于每个服务计算监控指标。根据您的编排工具，您可能希望在不同级别向下钻取。例如，在Kubernetes中，您通常有Namespaces、ReplicaSets、Pod和其他一些容器。聚合这些不同的层对于故障排除逻辑是必要的，独立于构成服务的容器的物理部署。3.监控弹性和多位置服务弹性服务并不是一个新概念，但它在原生容器环境中的变化比在虚拟环境中要快得多。快速变化会严重影响检测系统的正常运行。监控传统系统通常需要根据软件部署手动调整检查指标。这种调整可以像定义要捕获的单个指标一样具体，或者根据特定容器中应用程序的操作配置要收集的数据。在小范围内（比如几十个容器）我们可以接受，但是在大范围内是无法承受的。微服务的集中监控必须能够在没有人为干预的情况下随弹性服务自由增长和收缩。例如，如果DevOps团队必须手动定义容器中包含哪些服务以进行监控，他们无疑会错过，因为Kubernetes或Mesos每天都会定期创建新容器。同样，如果在代码发布和下放到生产环境时需要运维团队安装一个自定义的statsendpoint，也会给开发者从Docker仓库获取基础镜像带来更多的挑战。在生产环境中，为跨越多个数据中心或多个云的复杂部署设置监控，例如，如果你的服务跨越私有数据中心和AWS，Amazon的AWSCloudWatch就很难做到。这就需要我们搭建一个跨越不同地域，能够运行在动态原生容器环境中的监控系统。4、监控API在微服务环境下，API接口是通用的。本质上，它们是唯一向其他团队公开服务的组件。事实上，API的响应性和一致性可以看作是一个“内部SLA”，即使正式的SLA（服务水平协议）还没有定义。因此，对API接口的监控也是很有必要的。API监控可以有不同的形式，但绝对不是简单的二进制上下检查。例如，了解时间函数等最常用的端点很有价值。这允许团队看到服务使用的变化，无论是由于设计变化还是用户变化。您还可以记录服务的最慢端点，这些端点可能会揭示主要问题，或者至少指出系统中需要优化的区域。最后，跟踪系统服务响应的能力是另一个非常重要的能力。它主要供开发人员使用，同时也可以帮助您了解整体的用户体验，同时根据底层和应用的角度将信息分为两部分。5.将你的监控映射到你的组织结构这篇文章和其他技术文章一样关注微服务和监控，因为很多人关注这一层。对于熟悉康威定律的人来说，系统的设计是基于开发团队的组织结构。创建更快、更敏捷的软件的压力促使团队考虑重新调整他们的开发组织和管理它的规则。因此，如果他们想从这种新的软件架构（微服务）中受益，他们的团队必须将微服务映射到团队本身。也就是说，他们需要更小、耦合更松散的团队，只要能满足整体需求，就可以选择自己的方向。在每个团队中，将对开发语言的使用、错误提交甚至工作职责进行更大程度的控制。DevOps团队可以为此启用一个监控平台：每个微服务团队都可以拥有自己的警报、指标和仪表板，同时还提供整个系统的视图。总结让微服务流行的是捷径。开发组织想要更快地为客户提供更多的功能，微服务技术就来了。架构转向微服务，容器的流行让快速开发成为可能。所有相关流程都是理所当然的。最后，基本监控原则需要适应微服务附带的技术和结构。开发团队越早认识到这种转变，就越早也更容易适应微服务的新架构。
