微服务架构下的监控系统设计（一）——指标数据的采集展示

前言

微服务是一种架构风格，一个大型复杂软件应用通常由多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。

微服务之前很多单体应用，其监控复杂度较低，场景也比较单一。微服务下，由于业务逻辑散布在众多进程中（很多大型业务，一个业务流程涉及的服务有几十个），一旦业务出现问题，追查其源头就好比大海捞针，这个时候就需要完善的监控体系。

一个完善的监控体系，其构建周期比较漫长，而且随着业务场景的变化，自身也是需要不断迭代优化的。本文仅从几个监控维度以及原子化场景谈谈如何建立统一的监控数据收集、展示系统，希望能够启发大家继续深入地思考监控体系的建设。

微服务下的几个监控维度

微服务监控与传统应用的监控相比，最明显的改变就是视角的改变，我们把监控从机器视角转换成以服务为中心的视角，在微服务的视角下，监控可以从数据维度、资源维度和代码维度进行分层，如下图：

数据维度

当前WEB化服务是主流，每一个WEB服务都有一个入口，不管是APP还是WEB网页，入口负责跟用户交互，并将用户的信息发给后台，后台一般都会有接入LB或者Gateway，负责负载均衡并将数据转发给具体的应用处理，最后由应用处理之后写入数据库。

资源维度

现在很多服务部署在云端，涉及虚拟化技术，虚拟主机运行在物理服务器上，虚拟主机之间通过虚拟网络相互连接。在资源层面的监控，是不可缺少的一环，我们不但需要采集虚拟主机的性能指标，同时还需要知道运行虚拟主机的服务器上的CPU、内存、磁盘IO等数据，以及连接虚拟主机之间的虚拟网络的带宽负载等。

代码维度

APM，也就是应用性能分析，代码侧的监控采集，是随着微服务的兴起而出现的。在微服务场景下，一个业务流程横跨几十个服务的场景，只有传统的监控数据，很难定位到问题的根源。

我们可以针对代码的技术栈，开发出特定的采集框架，在性能损耗可以接受的范围之内，采集函数之间的调用关系，服务之间的调用拓扑，并测量函数或者服务的响应时间，才能有针对性地优化性能或者提前预判故障。

关键监控指标的场景描述

微服务监控最大的特点，用一句话概括：就是服务特别多，服务间的调用也非常复杂。当系统出现问题时，想要在上百个相关的、依赖错综复杂的服务系统之中快速定位到出错的系统，需要依靠关键的监控指标。我们在上述的三个维度之上，分析了每个维度下每个层级可能会产生的告警情况，总结了URL监控、主机监控、产品监控等八个原子化监控场景。

URL监控：无论是APP还是WEB，本质上都是通过URL发起后台调用，可以通过MOCK调用API获取响应时间、响应状态码等指标，展示监测业务的整体健康状况。

主机监控：通过安装代理采集主机上基本的监控信息如CPU、内存、IO等数据，同时用户可以通过配置文件打开其它开源应用如Tomcat、Nginx等数据采集开关。

产品监控：公有云将主机、网络、存储以及一些中间件以产品的形式提供给用户使用，产品服务后台上报各个产品相关指标数据，用来监控各个产品资源的健康状况。

组件监控：一些开源组件，比如Tomcat、Nginx、Netty等监控数据的采集，可以通过主机上的代理加载相应组件的监控采集程序。

自定义监控：服务实例收集业务相关数据，定时调用API接口上报数据，支持多个服务实例同时上报一个监控项，并且支持多维度查询告警。

资源监控：用户以资源为维度上报自定义数据，每个资源都有相同的几个监控项，各个资源的监控项之间相互独立。

APM：根据各语言栈的不同，分别实现函数调用关系、服务之间调用拓扑的展示。根据各个语言的不同，有的需要入侵代码，以SDK嵌入的形式收集数据，有的则与代码解耦，通过元编程重载一些方法来实现数据采集。

事件监控：针对公有云产品、业务逻辑中的不连续事件，比如云盘的不可用事件、SSD硬盘的Reset事件等，提供统一的存储、分析、展示。

有了以上原子化场景的数据收集，我们就可以通过UI统一展示监控数据，可以按照前文描述的三个维度，以用户体验为核心，设计图形化页面。图形化一般是以时间序列为横轴，展示指标随时间变化，针对一些统计指标，也可以通过饼图、柱状图等展示分析、对比结果。