支撑系统中全景监控技术研究实现（精品）.docx

《支撑系统中全景监控技术研究实现（精品）.docx》由会员分享，可在线阅读，更多相关《支撑系统中全景监控技术研究实现（精品）.docx（7页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、支撑系统中全景监控技术研究实现摘要:本文具体分析了移动应用支撑系统监控技术面临的各类问题，并提出了一种覆盖用户体验、后台系统、底层硬件等各个层面的全景监控技术，实现了移动应用后台支撑系统的统一监控与分析，并通过变点检测等方法及时发现监控数据的阴跌或暗涨等趋势变化。关键词:支撑系统；全景监控；全链路技术；变点检测随着移动互联网的快速发展，各类热门移动应用的后台支撑系统也随着前端应用的业务发展变得愈加强大与复杂，而监控系统在后台支撑中扮演的角色也越来越重要。怎样迅速监控到从用户体验、支撑系统乃至底层硬件的波动或者故障，并迅速定位问题，是移动应用后台监控系统面临的主要问题。1存在的问题通过对业界移动

2、应用后台支撑系统的监控系统进行整理与分析，发现主要存在下面几类问题。1.1用户侧体验缺乏监控用户在使用移动应用中一旦碰到应用闪退、白屏、卡顿、页面加载不完好、页面之间切换慢等问题会发生抱怨、投诉、甚至流失等情况，用户的使用体验和应用的口碑都会遭到较大影响。大部分移动应用的后台监控系统主要关注业务和系统等层面，用户体验的问题主要通过事前测试或者事后客户投诉来发现，缺乏能在用户使用经过中就及时发现批量出现用户体验问题的方案。1.2故障定位效率需提升很多移动应用的后台支撑系统经过一段时间的迭代建设后，功能层面不断完善，但是架构也越来越复杂，给监控系统的故障定位效率提出了新的挑战。比方各系统模块是通过

3、不同项目分期设计和上线，往往都有独立的监控工具如数据库有独立的监控工具，缓存模块有独立的监控工具，但监控的视野较窄且互相无关联，缺乏一致性的监控视角，经常出现各独立监控系统均有预警，系统运维人员却无法判定能否是同一故障引起，排障效率较低。1.3对趋势的预测能力弱传统的监控预警算法中，预警的阈值主要直接取自监控数据本身，但是对于阴跌和暗涨等数据缓慢变化，存在无法及时把控数据变化趋势，存在误报和漏报的可能。2移动应用支撑系统的全景监控技术基于业界移动应用后台支撑系统的监控技术存在缺乏对用户体验的监控、排障效率低、趋势预测能力弱等问题，本文提出了针对移动应用支撑系统的全景监控技术。2.1全景监控架构

4、全景监控在客户端应用层面增加了关于用户体验的监控，比方用户在应用中批量出现的客户端崩溃、白屏、页面切换慢等问题的监控，另外也实现了对应用级系统和底层硬件层面的监控，做到监控点全面分布，监控口径一致。从客户端到应用级系统缓存、中间件等再到底层硬件，信息全面采集，集中收集清洗，实时处理分析，各个层面通过数据流串联起来，统一监控与分析，如图1所示。2.1.1数据采集层以监控目的为维度进行划分，对下面各部分数据进行全面采集。1用户体验数据：利用自研的客户端和H5插码技术，对客户端的APP崩溃、ANR或白屏、H5页面加载慢或者出错等批量影响用户体验的异常情况进行采集。客户端和H5插码是通过在移动应用中集

5、成用户体验采集SDK来实现的，同时在对应的服务端架设Nginx+Lua环境的采集数据接收端，根据约定的格式及间隔时间，采集带时间戳的客户体验数据。详细采集流程如图2所示。本文中提及的用户体验采集SDK的逻辑架构如图3所示。整体上分为3层。最上层是接口层，提供APP调用的方法以及环境和配置参数等。第2层是业务层，包含了客户端各页面测速、卡顿检测和参数采集等所有的核心逻辑。第3层是数据层，将业务层产生的数据封装为统一的数据构造，并保存到本地文件或者数据库中。2应用系统数据：利用自研的Collectframework技术和业界热门的Metricbeat技术，实现对支撑系统中Nginx、缓存、服务中间

6、件和服务接口等各组件的运行状态数据进行采集。由于应用系统层面，各个厂商不同类型的组件较多，所以本文使用Collectframework技术，通过制定统一的采集标准和数据格式，对来自应用系统中Apache、HAProxy、MongoDB、MySQL、Nginx、Redis等不同技术和不同模块的数据进行统一采集。3底层硬件数据：利用业界热门的Metricbeat技术，对支撑系统的底层服务器硬件、CPU、内存、磁盘、文件系统、网络等各项进行采集。Metricbea将采集到的底层硬件数据定时传输到Redis缓存，经Logstash初步处理后进行存储。2.1.2数据清洗层负责汇总所有监控的初始数据，对这

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

8、清洗过的数据进行关联性分析，迅速发现监控目的的异常情况，并及时预警。数据分析层主要由监控分析模块与展现预警模块组成。1监控分析模块主要用于针对清洗后存储到Elasticsearch集群或者Opentsdb中的监控日志进行深度挖掘，分析系统的运行状况及各种性能问题。2展现预警模块一方面以图表的方式将监控目的的各种性能及状态指标集中呈现给运维人员，另一方面根据预警设置对各种监控到的异常情况进行预警和通知。2.2全链路监控技术全链路监控技术是以调用请求传递链路为入手点，将从用户体验到底层硬件的各个监控层面串联起来，关联监控并分析。此技术故障处理效率高，一旦发生故障，迅速定位故障点。在移动应用的支撑系

9、统中，用户在客户端的请求一般要经过用户端请求防火墙负载平衡反向应用端各能力服务缓存数据库应用中间件应用容器主机服务这样的一个长调用链路，各个环节的监控数据口径不统一，关联性不强，就算监控出数据异常，也很难迅速定位出详细的故障点。本文通过对分布式链路追踪技术的深化研究，实现了从用户体验到应用性能到主机和中间件的全链路监控。全链路监控系统的链路追踪技术遵从了谷歌Dapper链路的协议规范，其核心是基于Span的协议，依靠Span构建出服务调用的属性构造关系，进而通过树形构造的树形节点和叶子节点能够展示出分布式服务系统间的调用关系。整个调用经过的追踪流程如下。1系统一旦收到用户端请求，就生成一个全局

10、TraceID，通过TraceID能够串联起整个调用链，一个TraceID代表一次请求。2除了TraceID外，还需要SpanID用于记录调用父子关系。每个服务会记录下ParentSpanID和SpanID，通过他们能够组织一次完好调用链的父子关系。3一个没有ParentSpanID的Span成为rootSpan，能够看成调用链入口。4所有这些ID可用全局唯一的64bit整数表示。5整个调用经过中每个请求都要透传TraceID和SpanID。6每个服务将该次请求附带的TraceID和附带的SpanID作为ParentSpanID记录下，并且将本人生成的SpanID也记录下。7要查看某次完好的调

11、用则只要根据TraceID查出所有调用记录，然后通过ParentSpanID和SpanID组织起整个调用父子关系。全链路监控技术在监控平台中详细实现的界面如图4所示，通过此技术，运维人员可监控整条系统链路的运行情况以及各系统模块之间的调用关系，能够迅速定位出问题的故障模块和故障点并且迅速接入排障处理。2.3变点检测算法传统的监控预警算法对监控数据的微量波动、持续阴跌或者暗涨等问题经常不能及时发现，进而发生故障漏报。针对此问题，全景监控中引入了mean-shift等均值漂移模型与机器学习算法相结合来寻找监控数据的变点。所谓变点，就是持续微量下跌到一定时间，累积变化量到一定程度后，使得变点前后监测指标在一段时间内的均值发生漂移。从图5能够看到，均值漂移模型把传统监测预警算法不容易识别的阴跌趋势，转换成CUSUM时间序列并根据历史数据采用机器学习算法自动显示出变化趋势，在变点左侧单调增、右侧单调减，变点两侧单调变化。