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

前言

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

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

一个完善的监控体系，其构建周期比较漫长，并且随着业务场景的变化，自身也是须要不断迭代优化的。本文仅从几个监控维度以及原子化场景谈谈如何创建统一的监控数据收集、展现系统，但愿可以启发你们继续深刻地思考监控体系的建设。

微服务下的几个监控维度

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

数据维度

当前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统一展现监控数据，能够按照前文描述的三个维度，以用户体验为核心，设计图形化页面。图形化通常是以时间序列为横轴，展现指标随时间变化，针对一些统计指标，也能够经过饼图、柱状图等展现分析、对比结果。

本文主要阐述了监控体系中数据的采集、展现。至于数据的存储及告警流程，有兴趣的同窗能够继续关注后续监控相关文章。

做者介绍

董磊：UCloud技术专家。十年IT行业开发经验，目前负责UCloud混合云、监控产品的设计开发，持续关注微服务架构、监控、DevOps等领域。

更多技术干货，欢迎微信关注 “UCloud技术公告牌” 查看。