u采 采集(微服务下的几个监控维度（下）化服务)

　　u采 采集(微服务下的几个监控维度（下）化服务)

　　前言

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

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

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

　　微服务下的几个监控维度

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

　　数据维度

　　目前基于WEB的服务是主流。每个WEB服务都有一个入口，不管是APP还是WEB页面。入口负责与用户交互，将用户信息发送到后端。后端一般可以访问LB或者Gateway，负责负载。将数据平衡转发到特定的应用程序进行处理，最后由应用程序处理后写入数据库。

　　资源维度

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

　　代码维度

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

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

　　关键监测指标情景描述

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

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

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

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

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

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

　　资源监控：用户根据资源上报自定义数据。每个资源具有相同的监控项，每个资源的监控项相互独立。

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

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

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

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

　　关于作者

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

　　* 更多技术干货请关注微信“UCloud技术公告栏”查看。