文章采集调用(微服务下的几个监控维度（下）化服务)

　　文章采集调用(微服务下的几个监控维度（下）化服务)

　　前言

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

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

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

　　微服务下的几个监控维度

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

　　数据维度

　　目前的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硬盘Reset事件等，提供统一的存储、分析和展示。

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

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

　　关于作者

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