采集系统上云(微服务下的几个监控维度（下）化服务)

　　采集系统上云(微服务下的几个监控维度（下）化服务)

　　前言

　　微服务是一种架构风格，大型复杂的软件应用程序通常由多个微服务组成。系统中的每个微服务都可以独立部署，每个微服务都是松耦合的。每个微服务只专注于完成一项任务并把它做好。

　　在微服务之前，很多单体应用的监控复杂度较低，场景相对简单。在微服务下，由于业务逻辑分散在很多流程中（很多大业务，一个业务流程涉及几十个服务），一旦出现业务问题，追根溯源就像大海捞针。这时就需要完善的监控系统。

　　一套完整的监控系统建设周期长，需要随着业务场景的变化进行迭代优化。本文仅从几个监控维度和原子场景探讨如何建立统一的监控数据采集和展示系统，希望能启发大家继续深入思考监控系统的建设。

　　微服务下的几个监控维度

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

　　数据维度

　　目前，WEB服务是主流。每一个WEB服务都有一个入口，无论是APP还是WEB页面，入口负责与用户交互，并将用户的信息发送到后台。一般后台会访问LB或者Gateway，负责负载。将数据均衡转发给特定的应用程序进行处理，最后在应用程序处理完毕后写入数据库。

　　资源维度

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

　　代码维度

　　APM，即应用性能分析、代码端监控采集，是随着微服务的兴起而出现的。在微服务场景下，一个业务流程跨越数十个服务，仅靠传统的监控数据很难定位问题的根源。

　　我们可以针对代码的技术栈开发具体的采集框架，在可接受的性能损失范围内，采集函数之间的调用关系，服务之间的调用拓扑，只测量响应时间功能或服务的性能可以优化性能或提前预测故障。

　　关键监控指标场景描述

　　微服务监控的最大特点可以用一句话概括：服务很多，服务之间的调用也很复杂。当系统出现问题时，要想在数百个相关的错综复杂的业务系统中快速定位故障系统，就需要依靠关键的监控指标。基于以上三个维度，我们分析了各个维度下各个层级可能产生的告警，总结出URL监控、主机监控​​、产品监控等8个原子监控场景。

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

　　主机监控：通过安装agent采集对主机的基本监控信息如CPU、内存、IO等数据，用户可以通过配置文件打开其他开源应用如Tomcat、Nginx等数据< @采集 开关。

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

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

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

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

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

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

　　有了上述原子化场景的数据采集，我们就可以通过UI统一展示监控数据，并根据上述三个维度设计一个以用户体验为核心的图形化页面。图形一般以时间序列为横轴，显示指标随时间的变化。对于一些统计指标，还可以通过饼图和条形图的方式展示分析比较结果。

　　本文主要介绍监控系统中的采集和数据展示。至于数据存储和报警过程，有兴趣的同学可以继续关注后续监控相关的文章。

　　关于作者

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

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