支撑系统中全景监控技术研究实现范文

摘要:本文详细分析了移动应用支撑系统监控技术面临的各类问题，并提出了一种覆盖用户体验、后台系统、底层硬件等各个层面的全景监控技术，实现了移动应用后台支撑系统的统一监控与分析，并通过变点检测等方法及时发现监控数据的阴跌或暗涨等趋势变化。

关键词:支撑系统；全景监控；全链路技术；变点检测

随着移动互联网的快速发展，各类热门移动应用的后台支撑系统也随着前端应用的业务发展变得更加强大与复杂，而监控系统在后台支撑中扮演的角色也越来越重要。如何迅速监控到从用户体验、支撑系统乃至底层硬件的波动或者故障，并迅速定位问题，是移动应用后台监控系统面临的主要问题。

1存在的问题

通过对业界移动应用后台支撑系统的监控系统进行整理与分析，发现主要存在以下几类问题。

1.1用户侧体验缺乏监控

用户在使用移动应用中一旦遇到应用闪退、白屏、卡顿、页面加载不完整、页面之间切换慢等问题会发生抱怨、投诉、甚至流失等情况，用户的使用体验和应用的口碑都会受到较大影响。大部分移动应用的后台监控系统主要关注业务和系统等层面，用户体验的问题主要通过事前测试或者事后客户投诉来发现，缺乏能在用户使用过程中就及时发现批量出现用户体验问题的方案。

1.2故障定位效率需提升

许多移动应用的后台支撑系统经过一段时间的迭代建设后，功能层面不断完善，但是架构也越来越复杂，给监控系统的故障定位效率提出了新的挑战。比如各系统模块是通过不同项目分期设计和上线，往往都有独立的监控工具（如数据库有独立的监控工具，缓存模块有独立的监控工具），但监控的视野较窄且相互无关联，缺乏一致性的监控视角，经常出现各独立监控系统均有预警，系统运维人员却无法判断是否是同一故障引起，排障效率较低。

1.3对趋势的预测能力弱

传统的监控预警算法中，预警的阈值主要直接取自监控数据本身，但是对于阴跌和暗涨等数据缓慢变化，存在无法及时把控数据变化趋势，存在误报和漏报的可能。

2移动应用支撑系统的全景监控技术

基于业界移动应用后台支撑系统的监控技术存在缺乏对用户体验的监控、排障效率低、趋势预测能力弱等问题，本文提出了针对移动应用支撑系统的全景监控技术。

2.1全景监控架构

全景监控在客户端应用层面增加了关于用户体验的监控，比如用户在应用中批量出现的客户端崩溃、白屏、页面切换慢等问题的监控，另外也实现了对应用级系统和底层硬件层面的监控，做到监控点全面分布，监控口径一致。从客户端到应用级系统（缓存、中间件等）再到底层硬件，信息全面采集，集中收集清洗，实时处理分析，各个层面通过数据流串联起来，统一监控与分析，如图1所示。

2.1.1数据采集层以监控目标为维度进行划分，对以下各部分数据进行全面采集。（1）用户体验数据：利用自研的客户端和H5插码技术，对客户端的APP崩溃、ANR或白屏、H5页面加载慢或者出错等批量影响用户体验的异常情况进行采集。客户端和H5插码是通过在移动应用中集成用户体验采集SDK来实现的，同时在对应的服务端架设Nginx+Lua环境的采集数据接收端，按照约定的格式及间隔时间，采集带时间戳的客户体验数据。具体采集流程如图2所示。本文中提及的用户体验采集SDK的逻辑架构如图3所示。整体上分为3层。最上层是接口层，提供APP调用的方法以及环境和配置参数等。第2层是业务层，包含了客户端各页面测速、卡顿检测和参数采集等所有的核心逻辑。第3层是数据层，将业务层产生的数据封装为统一的数据结构，并保存到本地文件或者数据库中。（2）应用系统数据：利用自研的Collectframework技术和业界热门的Metricbeat技术，实现对支撑系统中Nginx、缓存、服务中间件和服务接口等各组件的运行状态数据进行采集。因为应用系统层面，各个厂商不同类型的组件较多，所以本文使用Collectframework技术，通过制定统一的采集标准和数据格式，对来自应用系统中Apache、HAProxy、MongoDB、MySQL、Nginx、Redis等不同技术和不同模块的数据进行统一采集。（3）底层硬件数据：利用业界热门的Metricbeat技术，对支撑系统的底层服务器硬件、CPU、内存、磁盘、文件系统、网络等各项进行采集。Metricbea将采集到的底层硬件数据定时传输到Redis缓存，经Logstash初步处理后进行存储。

2.1.2数据清洗层负责汇总所有监控的初始数据，对这些数据进行清洗，过滤掉有问题或者不完整的数据，并将其进行统一的结构转换和标记，提取必要的信息，从而便于分析及存储。原始的监控日志由于各种原因会存在日志格式不完整、信息丢失等现象，所以需要将无效的数据进行规整删除，对部分数据进行适当的转换，比如日期的时区转换等，才能确保监控分析的准确。本文中的数据清洗层主要使用的工具是Logstash，具体清洗过程如下。（1）Logstash从缓存队列中获取监控日志数据。（2）Logstash通过其Filter插件对监控数据进行清洗和转换。（3）将清洗和转换后的监控数据进行存储至Elasticsearch集群或者Opentsdb中供数据分析层使用。

2.1.3数据分析层负责对清洗过的数据进行关联性分析，迅速发现监控目标的异常情况，并及时预警。数据分析层主要由监控分析模块与展现预警模块组成。（1）监控分析模块主要用于针对清洗后存储到Elasticsearch集群或者Opentsdb中的监控日志进行深度挖掘，分析系统的运行状况及各种性能问题。（2）展现预警模块一方面以图表的方式将监控目标的各种性能及状态指标集中呈现给运维人员，另一方面根据预警设置对各种监控到的异常情况进行预警和通知。

2.2全链路监控技术

全链路监控技术是以调用请求传递链路为入手点，将从用户体验到底层硬件的各个监控层面串联起来，关联监控并分析。此技术故障处理效率高，一旦发生故障，迅速定位故障点。在移动应用的支撑系统中，用户在客户端的请求一般要经过用户端请求→防火墙→负载均衡→反向→应用端→各能力服务→缓存→数据库→应用中间件（应用容器）→主机服务这样的一个长调用链路，各个环节的监控数据口径不统一，关联性不强，就算监控出数据异常，也很难迅速定位出具体的故障点。本文通过对分布式链路追踪技术的深入研究，实现了从用户体验到应用性能到主机和中间件的全链路监控。全链路监控系统的链路追踪技术遵从了谷歌Dapper链路的协议规范，其核心是基于Span的协议，依赖Span构建出服务调用的属性结构关系，从而通过树形结构的树形节点和叶子节点能够展示出分布式服务系统间的调用关系。整个调用过程的追踪流程如下。（1）系统一旦收到用户端请求，就生成一个全局TraceID，通过TraceID可以串联起整个调用链，一个TraceID代表一次请求。（2）除了TraceID外，还需要SpanID用于记录调用父子关系。每个服务会记录下ParentSpanID和SpanID，通过他们可以组织一次完整调用链的父子关系。（3）一个没有ParentSpanID的Span成为rootSpan，可以看成调用链入口。（4）所有这些ID可用全局唯一的64bit整数表示。（5）整个调用过程中每个请求都要透传TraceID和SpanID。（6）每个服务将该次请求附带的TraceID和附带的SpanID作为ParentSpanID记录下，并且将自己生成的SpanID也记录下。（7）要查看某次完整的调用则只要根据TraceID查出所有调用记录，然后通过ParentSpanID和SpanID组织起整个调用父子关系。全链路监控技术在监控平台中具体实现的界面如图4所示，通过此技术，运维人员可监控整条系统链路的运行情况以及各系统模块之间的调用关系，能够迅速定位出问题的故障模块和故障点并且迅速接入排障处理。

2.3变点检测算法

传统的监控预警算法对监控数据的微量波动、持续阴跌或者暗涨等问题常常不能及时发现，从而发生故障漏报。针对此问题，全景监控中引入了mean-shift等均值漂移模型与机器学习算法相结合来寻找监控数据的变点。所谓变点，就是持续微量下跌到一定时间，累积变化量到一定程度后，使得变点前后监测指标在一段时间内的均值发生漂移。从图5可以看到，均值漂移模型把传统监测预警算法不容易识别的阴跌趋势，转换成CUSUM时间序列并根据历史数据采用机器学习算法自动显示出变化趋势，在变点左侧单调增、右侧单调减，变点两侧单调变化。

参考文献

[1]刘嘉裕.基于分布式微服务全链路实时监控系统设计与实现[D].北京：北京交通大学，2018.

[2]李拂晓.几类时间序列模型变点监测与检验[D].西安：西北工业大学，2015.

[3]刘一田,刘士进,郭伟.柔性微服务监控框架[J].计算机系统应用,2017(10).

[4]苏卫星,朱云龙,刘芳.时间序列异常点及突变点的检测算法[J].计算机研究与发展,2014,51(4):781-788.

作者：李映 单位：中国移动通信集团江苏有限公司