订阅业界RSS CSDN首页> 业界

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

发表于2018-08-01 17:31| 来源Ucloud| 作者Ucloud

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

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

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

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

            首先我们大概介绍下监控的维度,如图:

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

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

以上便是监控的三个常规维度介绍,下面介绍下针对这些维度,我们可以采用的监控手段,如下图:

       代码维度:也就是APM,应用性能分析,代码侧的监控采集,是随着微服务的兴起而出现的。在微服务场景下,一个业务流程横跨几十个服务的场景,只有传统的监控数据,很难定位到问题的根源。我们可以针对代码的技术栈,开发出特定的采集框架,在性能损耗可以接受的范围之内,采集函数之间的调用关系,服务之间的调用拓扑,并测量函数或者服务的响应时间,才能有针对性地优化性能或者提前预判故障。

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

       主机监控:通过安装代理采集主机上基本的监控信息如CPU、MEM、IO等数据,同时用户可以通过配置文件打开其它开源应用如TOMCAT、NGINX等数据采集开关。

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

       组件监控:一些开源组件,比如TOMCAT、NGINX、NETTY等监控数据的采集,可以通过主机上的代理加载相应组件的监控采集程序。

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

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

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

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

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

       由于篇幅限制,本文主要阐述了监控体系中数据的采集、展示,至于数据的存储及告警流程,有兴趣的同学可以继续关注后续监控相关文章。

作者介绍

董磊:UCloud技术专家。08年毕业后先后在中兴华为做数通产品的开发,目前在UCloud,先后从事混合云系统开发、监控系统设计开发,关注微服务架构、监控、DEVOPS等领域。 

0
0