监测云计算系统

计算机学报2016年在线发布CHINESEJOURNALOFCOMPUTERS2016Online本课题得到国家自然科学基金(No.
61402450)、北京市自然科学基金(No.
4154088)、CCF-启明星辰"鸿雁"科研资助计划(No.
CCF-VenustechRP2016007)、国家科技支撑计划(No.
2015BAH55F02)、国家高技术研究发展计划(No.
2013AA041301)资助.
王焘(通讯作者),男,1982年,博士,助理研究员,中国计算机学会(CCF)会员(No.
E200039430M),主要研究领域为软件运行时监控、软件故障检测、自主计算、云计算,E-mail:wangtao@iscas.
ac.
cn;顾泽宇,男,1991年,硕士,主要研究领域为分布式监测;张文博,男,1976年,博士,研究员,博士生导师,主要研究领域为分布式计算和软件工程;徐继伟,男,1985年,博士研究生,主要研究领域为分布式计算和软件工程;魏峻,男,1970年,博士,研究员,博士生导师,CCF高级会员,主要研究领域为分布式计算和软件工程;钟华,男,1971年,博士,研究员,博士生导师,CCF高级会员,主要研究领域为分布式计算和软件工程.
一种基于自适应监测的云计算系统故障检测方法*王焘顾泽宇张文博徐继伟魏峻钟华(计算机科学国家重点实验室,北京100190)(中国科学院软件研究所,北京100190)摘要监测技术是保障云计算系统性能与可靠性的关键,管理员通过分析监测数据可以了解系统运行状态,从而采取措施以及早发现并解决问题.
然而,云计算系统规模巨大,结构复杂,大量的监测数据需要搜集、传输、存储和分析,对系统造成巨大性能开销.
那么,如何提高故障检测的准确性和及时性的同时,减少监测开销成为亟待解决的问题.
为了应对以上问题,本文提出一种基于自适应监测的云计算系统故障检测方法.
首先,利用相关分析建立度量间的相关性,利用度量关联图选择关键度量进行监测;而后,利用主成分分析得到监测数据的主特征向量以刻画系统运行状态,进而基于余弦相似度评估系统异常程度;最后,建立可靠性模型以预测系统可能出现故障的时间,基于此动态调整监测周期.
实验结果表明,本文所提出的方法能够适应云环境下负载的动态变化,准确评估系统异常程度,自动调整监测频率以提高系统在异常状况下故障检测的准确性与及时性,同时降低系统在正常运行过程中的监测开销.
关键词故障检测;自适应监测;云计算;相关分析;主成分分析AdaptiveMonitoringbasedFaultDetectionforCloudComputingSystemsWANGTao,GUZe-yu,ZHANGWen-bo,XUJi-wei,WEIJun,ZHONGHua(StateKeyLaboratoryofComputerScience,Beijing100190)(InstituteofSoftware,ChineseAcademyofSciences,Beijing100190)AbstractMonitoringisthekeytechnologyofguaranteeingtheperformanceandreliabilityofdistributedsystems.
Byanalyzingmonitoringdata,administratorscanunderstandthesystems'statustodetect,diagnoseandsolveproblems.
However,theprocedureofcollecting,transmitting,storingandanalyzingalargeamountofmonitoringdatafromlarge-scalecloudcomputingsystemsintroducesenormousperformanceoverhead.
Toaddresstheaboveissue,thispaperproposesanadaptivemonitoringapproachforfaultdetection.
First,weconductcorrelationanalysisbetweendifferentmetricstoconstructanundirectedcorrelationgraph,andmonitoronlyselectedimportantmetricsfromthegraph,whichcanrepresenttheotheronesandreflecttherunningstatusofthewholesystem.
Second,weusePrincipalComponentAnalysis(PCA)tocharacterizetherunningstatusbasedonthemonitoringdatafromaslidingwindowtoestimatetheabnormalitydegreeandpredictthepossibilityofsystemfaultsbycomparingthecurrentandthehistoricalcollectedmonitoringdata.
Finally,we2计算机学报2016年dynamicallyadjustthemonitoringperiodbasedontheestimatedabnormalitydegreeandareliabilitymodel.
Toevaluateourproposal,wehaveappliedtheapproachinaTPC-Wbenchmarkdeployedinourcloudcomputingplatform.
Theexperimentalresultsdemonstratethattheapproachcanadapttothedynamicworkloadfluctuation,accuratelyestimatetheabnormalitydegree,andautomaticallyadjustthemonitoringfrequency.
Thus,theapproachcaneffectivelyimprovetheaccuracyandtimelinessoffaultdetectionintheabnormalstatus,andefficientlylowerthemonitoringoverheadinthenormalstatus.
KeywordsFaultdetection;AdaptiveMonitoring;CloudComputing;CorrelationAnalysis;PrincipleComponentAnalysis1引言近年来,云计算技术飞速发展,已经广泛应用于诸多领域,成为当前信息技术产业发展和应用创新的热点.
国内外大型IT企业纷纷推出云计算平台(如AmazonEC2、阿里云),同时开源云计算平台(如Eucalyptus、OpenStack)的出现也促进了云计算技术研究与应用的发展.
目前,电子商务、互联网金融、社交网络等在线服务已经成为人们日常工作和生活中不可或缺的一部分,其中众多应用部署在云计算平台依托于云服务(如SaleforceCRM、Netflix).
本文将这些部署在云计算平台上的分布式软件系统称为云计算系统.
然而,应用的多样性以及部署环境的动态性使得云计算系统时常会出现故障,从而严重影响人们正常的工作生活,甚至在商业方面造成巨大的经济损失[1].
例如2013年8月亚马逊网站宕机约45分钟,在宕机期间消费者无法通过网站以及移动客户端进行购物,从而造成经济损失约达530万美元1.
在云计算系统运行过程中,高效监测是及时检测系统故障并准确定位问题原因的前提条件.
云计算系统规模巨大、结构复杂,监测系统需要从众多节点上搜集多个层次(如网络层、硬件层、虚拟机层、操作系统层、中间件层、应用软件层)各种资源的监测数据,以持续跟踪云计算系统的运行状态.
然而,搜集、传输、存储与分析大量监测数据将会带来巨大资源开销,从而影响系统性能,异常检测的及时性,以及问题定位的准确性.
而商业监测系统(如亚马逊的CloudWatch)只支持固定的较长的监测周期(如每分钟搜集一次监测数据).
同时,从用户角度考虑,租用云监测服务需要支付的费用与监测的对象和频率成正比,而监测花费占到了总共运行成本的18%2.
这样就造成了,一方面,管理员和用户希望减少监测对象和降低监测频率(即单位时间内的搜集监测数据的次数)以减少开销和降低成本.
另一方面,故障可能在连续监测的时间间隔内发生,监测对象过少以及监测频率过低会减少Amazon.
comgoesdownfor45minutes,loses$5Minbusiness.
http://techcircle.
vccircle.
com/2013/08/20/amazon-website-goes-down-on-monday-company-loses-5m-in-business.
2013,8,20.
AmazonEC2CloudWatch.
http://aws.
amazon.
com/cloudwatch/.
2012.
可用监测数据量,从而降低了检出故障的准确性与及时性.
那么,如何设置监测对象与频率,成为监测云计算系统并保障其可靠性的关键.
当前,大规模数据中心监测主要关注于监测系统架构和传输协议设计,以降低监测对网络造成的压力.
管理员通常根据领域知识,针对不同应用场景,选择特定监测对象,人工设定数据搜集内容和频率调整规则,这种方法适用系统有限,且规则设定的优劣直接影响监测效果.
云计算环境下,应用呈现多样性,且应用对云平台是透明的,系统管理员难以设定面向特定领域的监测规则.
针对上述问题,本文提出一种基于自适应监测的云计算系统故障检测方法.
首先,利用相关分析分析度量间的相关性,从众多度量中选取反映系统运行状态的关键度量.
然后,根据滑动窗口中搜集的监测数据,利用主成分分析(PrincipalComponentAnalysis,PCA)刻画系统运行状态以评估系统异常程度,预测系统故障发生的可能性.
进而,基于可靠性模型与异常程度,动态调整监测周期.
实验结果表明,本文所提出的方法能够适应云环境下负载的动态变化,准确评估系统异常程度,自动调整监测频率以提高系统在异常状况下故障检测的准确性与及时性,同时降低系统在正常运行过程中的监测开销.
本文第2节介绍了所提出方法的整体思路;第3节给出了基于故障检测的自适应监测方法;第4节通过实验验证本文所提出方法的有效性;第5节分析并比较相关工作;第6节对文章内容进行总结.
2整体思路监测对象和监测周期是影响系统监测开销、故障检测准确性与及时性的关键.
因此,本文首先基于历史数据分析度量间的相关性从而选取反映系统运行状态的关键度量,而后根据系统出现故障的可能性自适应调整监测周期.
在监测对象选择方面,云计算系统各个层次存在众多的资源的使用情况需要监测,会造成巨大的监测开销.
减少监测对象是提高监测效率的重要途径.
系统中不同度量对运行状态的表现力是不同,因此需要从众多度量中选取最能反映系统出现故障可能性的度量.
王焘等:一种基于自适应监测的云计算系统故障检测方法3在监测周期调整方面,当系统出现故障的可能性较高时,缩短监测周期,搜集更多监测数据,以密切跟踪系统运行状态,从而提高故障检测的准确性和及时性.
反之,当系统出现故障的可能性较低时,延长监测周期,从而降低监测开销.
由于在整个系统运行过程中,故障出现的概率相对较少,动态调整监测周期可以减少大量监测开销,对于云环境下高效可扩展监测相当重要.
IBM提出了自主计算参考模型MAPE-K(Monitor,Analyze,Plan,Execution,Knowledge),该模型由若干相互联系的自主元素组成,这些元素通过交互和协作实现计算系统自适应的自动管理[2].
本文基于该模型实现面向云计算系统的自适应监测框架,根据云计算系统运行状态自适应调整监测对象和监测周期,以减少系统在正常运行状态的监测开销,并提高系统在异常状态的错误检测的准确性与及时性.
如图1所示,框架中包括MAPE-K模型中的自主元素:(1)监测器(Monitor):监测代理部署在物理主机、虚拟机或者容器上,用以搜集各层次的监测数据并进行持久化存储.
(2)分析器(Analyzer):根据历史监测数据,建立度量间的相关性形成度量关联图以评估度量的重要程度,并利用PCA计算监测数据的特征向量以量化评估系统异常程度.
(3)规划器(Planner):根据监测对象重要性选择下阶段需要监测的对象.
利用泊松过程建立软件系统可靠性模型,基于异常程度预测系统故障发生的可能性以调整监测周期.
(4)执行器(Executor):利用监测代理执行监测对象与监测周期的动态调整.
(5)知识库(Knowledge):记录运行过程中学习到的负载模式以及对应的特征向量,以刻画系统正常运行状态.
3自适应监测方法3.
1关键度量选择云计算系统中多种资源利用之间往往具有相关性[3],需要监测的系统度量之间普遍存在稳定的线性关系[4].
皮尔逊(Pearson)相关系数用来测量两个变量间的线性相关程度,取值在-1到1之间,系数取值为1表示两个变量完全正相关,系数取值为-1表示两个变量完全负相关,系数取值为0表示两个变量完全不相关.
本文采用Pearson相关系数来计算度量间的线性相关性,通过一个度量来反映与其相关的其他度量.
这样就可以只监测一部分度量,就能够推图1云计算系统自适应监测框架4计算机学报2016年断出其余度量的变化,从而减少监测度量数量,达到降低监测开销的目的.
算法描述如算法1所示,具体步骤如下:(1)计算任意两个度量之间的相关系数,如表1所示,当度量x和度量y强相关.
表1相关性定义相关系数(r)r2相关强度[0,0.
2)[0,0.
04)不相关[0.
2,0.
4)[0.
04,0.
16)一般[0.
4,0.
6)[0.
16,0.
36)弱相关[0.
6,0.
8)[0.
36,0.
64)相关[0.
8,1.
0][0.
64,1]强相关(2)用n节点无向图来描述度量间的相关性,图中节点代表度量,当两度量强相关则节点间有无向边连接,用n*n矩阵来可刻画度量相关图Ann.
每个节点的权重为与其连接的节点数量(即边数).
(3)选择权重最大的节点,删除与其相连的边和节点,并更新图以及各节点权值.
重复以上操作,直到图中节点数目为零.
算法1中,相关系数阈值的设定直接影响到监测的开销以及故障检测与问题定位的准确性.
如果阈值设置过高,则众多度量会被认为不相关,那么这些度量就不能够被其他度量所代表,都会被纳入监测范围之内,从而增加了监测开销.
相反,如果阈值设置过低,众多度量虽然相关度低,但也会被其他度量所代表,当出现与这些度量相关的问题,异常表现也并不明显,从而造成故障的漏报,或者由于缺少这些度量的监测数据而不能准确定位问题原因.
为了保证故障检测以及问题定位的准确性,本文付出部分监测开销的代价.
根据文献[5],将相关性的阈值设置为0.
8,即当度量间是强相关的时候才将这两个度量做相关处理,以适当减少监测度量.
算法1.
关键度量选择输入:监测数据集合其中,x,y为度量监测值.
输出:关键度量集合MS.
1.
计算任意两个度量x,y之间的相关系数:,其中,.
2.
建立度量相关图Ann:,其中,n为DS中数据实例数量.
计算任意度量i的权重:.
3.
WHILE(TRUE){选取数组w中最大值w[a];IF(w[a]=-1)THENRETURN(集合N);w[a]=-1;节点集合;FOR(j=a+1;jx)=P(N=0)=e-λx,x≥0.
X的累积分布函数为:F(x)=P(X≤x)=1-e-λx,x≥0.
其中,X是以λ为参数的指数随机变量,表示泊松过程中的连续出现故障的时间间隔;λ为泊松过程中单位时间内平均出现故障的次数.
由于在泊松过程中,一定时间间隔内出现一定数量故障的概率只与间隔时间长短有关,X的开始时间点的选取与预测故障发生的时间点无关.
设系统出现故障的概率为F(t)=w,那么可以由此计算出下一次出现故障的时间间隔:t=-ln(1-w)/λ,x≥0,因此本文将当前的监测周期调整为:,(4)其中,Tβ为最小监测周期,Tα为最大监测周期,为调整参数.
下边对其取值进行讨论:1)最小监测周期Tβ,需要考虑系统允许的监测所带来的最大开销,同时可以基于经验值或由系统当前负载所决定,例如,负载为50个请求每分钟,那么如果监测周期设定为1秒,则不能够得到所期望的监测值.
2)最大监测周期Tα,需要考虑系统检测故障的及时性,例如,若设定α为60%,就意味着在两次监测之间有60%的概率系统已经出现了故障.
表2实验配置主机硬件配置软件配置1Intel(R)Xeon(R)CPUE5645,2.
40GHz,24Cores,24GBRAM操作系统:Centos7.
1;负载生成器:Bench4Q1.
0;负载均衡器(LB):Apache2.
4.
182、3Intel(R)Core(TM)i5-3470,3.
20GHz,24Cores,16GBRAM操作系统:Centos7.
1;应用服务器(AS):Tomcat9.
0;Web应用:Bench4Q1.
04Intel(R)Core(TM)i5-3470,3.
20GHz24Cores,32GBRAM操作系统:Centos7.
1;数据库服务器(DB):MySQL5.
6王焘等:一种基于自适应监测的云计算系统故障检测方法73)由于当时,当时,因此只需要设定,并将其代入式(4)中,即可以计算得到参数的取值.
对函数进行分析可以得到,监测周期在设定的最大监测周期和最小监测周期之间,随着系统异常程度增加而缩短,并且随着异常程度的加剧监测周期缩短的幅度增加,即异常越严重监测周期缩短的越快,这是期望得到的结果.
本文量化了异常程度而不是简单的判断异常与否,通常情况下异常程度也是逐渐变化的连续过程,监测周期也随异常程度不断动态变化,能够反映系统异常变化的趋势.
同时,如果在监测周期动态调整的过程中出现了突发性的异常,监测周期的最大阈值也保证了故障检测的准确性和及时性并不会受到太大影响.
4实验评价4.
1实验环境本文基于由中国科学院软件研究所自主研发的类似于亚马逊EC2的云计算服务平台OnceCloud3,部署开源的典型多层电子商务基准测试系统Bench4Q4,构成实验环境.
本文将所提出的动态监测方法应用在该实验平台,向系统中随机注入故障以验证方法的有效性.
具体实验环境如图2所示,由四台刀片服务器构成,每台服务器启动若干Docker容器,部署应用程序,系统各组件配置信息如表2所示.
Bench4Q是遵循TPC-W规范5的基准测试应用,采用企业应用的典型三层架构,其中包括三种常用的开源服务器系统,负载均衡器Apache6以进行请求分发,应用服务器Tomcat7集群以处理业务逻辑,数据库服务器MySQL8以提供数据操作.
TPC-W是当前广泛采用的企业应用基准测试规范,遵循该规范的Web应用实现了在线电子商务应用.
TPC-W定义了三种负载模式,包括浏览、查询和购买商品.
客户在一个会话中通过一些列连续操作来访问Web站点.
为了模拟实际云计算环境下负载变化的动态性,本文扩展了Bench4Q原有的负载发生OnceCloud.
http://www.
once.
org.
cn/OncePortal/oncecloudBench4Q.
http://www.
ow2.
org/view/ActivitiesDashboard/Bench4QTPC-W.
http://www.
tpc.
org/tpcwApache.
http://httpd.
apache.
org.
ApacheTomcat.
http://tomcat.
apache.
org.
MySQL.
http://www.
mysql.
com图2实验架构表3故障注入列表资源类型故障类型故障描述执行的操作CPU进程死锁模拟多进程竞争共享变量,造成CPU占用过高额外操作分别占用CPU时间(1)20%,(2)40%,(3)60%,(StressLinux)磁盘I/O干扰创建Docker容器,部署应用执行磁盘I/O操作,造成I/O性能干扰额外操作使用2个线程执行sync()函数,另一个线程执行write()函数,分别向磁盘写入(1)128MB,(2)256MB,(3)384MB(StressLinux)网络网络传输拥塞模拟发包请求占用一定量的网络带宽额外操作通过向其他网络节点发送数据包分别占用当前节点(1)20%,(2)40%,(3)60%的网络带宽(iPerf)内存内存泄露创建对象引用静态变量,造成该对象不被垃圾回收,逐渐耗尽内存资源每当故障触发则创建对象,并指向全局静态变量,以免被垃圾回收,逐渐占用2GB内存8计算机学报2016年器,并发数量与负载模式在运行过程中动态变化.
本文利用滑动窗口技术临时存储监测数据,主要实现两方面的功能:首先,计算当前滑动窗口中的度量向量集合的特征向量,将其与基准特征向量进行比较以检测故障;其次,根据当前滑动窗口中的负载向量集合学习新的负载模式,在特定负载模式下检测故障.
每当新的监测数据到来则加入滑动窗口末尾,并将窗口最前的监测数据删除.
窗口长度越大,故障表现越不明显,故障检测的及时性越差,从而导致较高的漏报率;相反,窗口长度越小,故障表现越显著,但噪音监测数据所造成的影响会越大,从而导致较高的误报率.
实验结果表明,窗口长度在15-25的时候,故障检测的效果较为理想,且差别不大,因此在本章实验中将滑动窗口大小设置为20,由于篇幅限制本文未给出具体实验数据.
4.
2实验结果4.
2.
1监测度量选择在监测数据搜集方面,本文对开源分布式监测系统Zabbix9进行扩展从处理器、内存、磁盘、网络等四类资源搜集到26个系统监测度量.
对于每类资源,利用相关分析选取其中的关键度量进行监测分析,最终选择的结果如表4所示,进行在线分析,以评估系统异常程度.
由于篇幅限制,本文仅以网络相关度量为例.
网络相关搜集到的度量共8项如表4Docker关键监测度量资源类型度量索引值说明CPUsystem_cpu_usage系统调用所占CPU时间片网络rx_packets接收的数据包个数tx_errors发送的数据包个数内存used当前容器已使用内存量pgpgin从磁盘或swap置换到内存的字节数磁盘read读取的字节数write写入的字节数表5所示,根据3.
1所提出的方法,计算这些度量的相关性如图3所示,最后得到关键度量rx_packets和tx_errors进行进一步的监测分析.
Zabbix.
http://www.
zabbix.
com王焘等:一种基于自适应监测的云计算系统故障检测方法94.
2.
2动态负载的适应性在云计算环境下,负载动态变化,而负载由并发数量与负载模式共同刻画[6].
本文通过模拟不断变化的负载来验证PCA能够适应负载的动态变化,即系统在正常运行过程中,虽然并发数量以及负载模式在不断改变,但由PCA计算得到的特征向量的主方向依然保持稳定.
在本实验中,并发数量由0以步长为2逐渐增加到300,每种并发数量持续5分钟,实验持续750分钟,每5分钟搜集一组监测数据,可以获取150组数据.
本文中滑动窗口长度设置为20,那么本文将前20组数据用作基准训练数据计算PCA特征向量的主方向,此后的数据可用作在线故障检测.
表4Docker关键监测度量资源类型度量索引值说明CPUsystem_cpu_usage系统调用所占CPU时间片网络rx_packets接收的数据包个数tx_errors发送的数据包个数内存used当前容器已使用内存量pgpgin从磁盘或swap置换到内存的字节数磁盘read读取的字节数write写入的字节数表5网络度量说明度量索引说明tx_packets发送的数据包个数rx_bytes收到的字节数tx_bytes发送的字节数rx_errors接收数据时出现的错误数tx_errors发送数据时出现的错误数rx_dropped接收数据时丢弃的包的个数tx_dropped发送数据时丢弃的包的个数rx_packets收到的数据包个数图3网络度量相关性10计算机学报2016年本文将异常程度阈值设置为0.
2,即当高于阈值则判定为异常.
本文根据系统异常程度,动态调整监测周期,与阈值无关,不影响监测周期调整.
该阈值只是与发出异常警报相关,如果阈值设定过高,系统异常程度升高而不报警,从而影响检测的及时性;如果阈值设定过低,系统处于正常状态也会报警,从而造成误报.
在实际系统中,报警阈值通常根据系统管理员经验来设定,例如当前系统管理员会设定CPU利用率阈值为95%,当超过才报警.
本文利用离线测试将正常运行状况下95%数据所处区域的异常值设定为阈值,离线测试结果可参考图5.
(1)负载模式不变,并发数量变化负载模式保持Browsing不变,实验结果如图4所示,横坐标为并发数量,纵坐标为异常程度为(1-|余弦相似度|),取值在0到1之间,异常程度最大值为1,表示系统已出现问题,最小值为0,表示系统状态完全正常.
在负载模式不变,并发数量变化的情况下,没有正常监测数据检测为异常情况的误检现象的发生.
因此,对并发数量动态变化的情况有较好的适应性.
(2)并发数量和负载模式都发生变化负载模式以Browsing、Shopping、Ordering等三种方式顺序变化,每种负载并发递增50,即Browsing(并发:1-50,151-200)、Shopping(并发:51-100,201-250)、Ordering(并发:101-150,251-300).
实验结果如图5所示,在并发数量和负载模式变化的情况下,15个数据点检测为异常,误检率为5%.
因此,所提出的方法具有较好的鲁棒性,能够适应负载不断变化的云计算环境.
4.
2.
3异常程度评估的准确性由于目前尚无云应用故障注入的Benchmark,为了保证注入故障的典型性,本文参考文献[11]分析Web应用服务失效的常见原因,选取Web应用的四类典型故障进行注入,包括CPU、磁盘、网络和内存,如表3所示.
系统运行过程中,当所注入的额外操作代码被调用则触发故障.
这些故障本文通过所注入的故障代码调用压力测试工具的命令行来实现.
对于CPU和磁盘等资源占用,本文利用图4异常程度随并发量变化图5异常程度随负载变化图6CPU相关故障注入图7磁盘相关故障注入图8网络相关故障注入王焘等:一种基于自适应监测的云计算系统故障检测方法11StressLinux10来实现,其广泛用于压力测试和调试系统组件失败.
对于网络资源占用,本文利用网络性能测试工具iPerf11来实现,其可以通过TCP和UDP发包来占用带宽资源.
本实验中,并发数量由0以步长为2逐渐增加到240,每种并发数量持续5分钟,负载模式从Browsing、Shopping、Ordering三种模式中随机选取,每5分钟搜集一组监测数据,每个实验持续600分钟,可以获取120组数据.
本文中滑动窗口长度设置为20,那么本文将前20组数据用作基准训练数据计算PCA特征向量的主方向,此后的数据可用作在线故障检测.
在每个实验中注入一种错误,实验结果如图6图7图8所示,运行过程包括以下阶段:正常运行(并发:0-60)、注入故障(1)(并发:61-120)、注入故障(2)(并发:121-180)、注入故障(3)(并发:181-240),在CPU、磁盘、网络等相关故障注入系统后,随着注入故障的严重程度增加,系统的异常程度也逐渐增加.
因此,本文所提出方法可以检测到故障所引起的系统异常,并且能够反映异常的严重程度.
4.
2.
4监测开销对比在不注入错误的情况下,实验持续60分钟.
固定监测周期与动态调整监测周期的监测方法对应的CPU利用率如图9(a)所示.
从图中可以看出,动态调整监测周期的方法对应的CPU利用率始终维持在较低水平.
这是由于系统运行状况稳定,异常程度较低,监测系统采用了较大的监测周期,监测数据收集次数较少.
从图9(b)可以看出监测周期的变化对网络流量的影响.
固定监测周期的方法每分钟内发送的网络流量始终维持在固定范围内,而动态调整监测周期的方法由于系统异常程度较低,会逐渐采用较大的监测周期,进行数据收集的次数减少,因此每分钟内发送的网络流量呈逐渐减少的趋势.
我们从MySQL的bug列表中选取MySQL5.
5.
5-m3版本的54332号错误.
该错误的产生是由于两个连接访问同一个表,每个连接都用LOCKTABLEWRITE将表锁定,在另一个表上执行INSERTDELAYED会产生死锁.
该错误的注入方法如表6所示.
StressLinux.
http://www.
stresslinux.
org/sl/iPerf.
https://iperf.
fr/(a)不注入错误时CPU利用率对比(b)不注入错误时网络流量对比(c)注入错误时CPU利用率对比(d)注入错误时网络流量对比图9监测开销对比12计算机学报2016年表6MySQL5.
5.
5-m3的54332号错误注入方法CREATETABLEt1(aINT);CREATETABLEt2(aINT);connect(con1,localhost,root);LOCKTABLEt1WRITE;connectiondefault;LOCKTABLEt2WRITE;--sendINSERTDELAYEDINTOt1VALUES(1)connectioncon1;--sleep1INSERTDELAYEDINTOt2VALUES(1);在注入错误以后,不同监测方式对应的CPU利用率如图9(c)所示,从图中可以看出,在30-55分钟和90-115分钟这两个注入错误的时间段,动态调整监测周期的方法比采用固定监测周期的方法消耗的CPU略高,因为这两个时间段系统异常程度较高,动态调整监测周期的方法会使监测系统采用更小的监测周期,执行更多的监测数据收集操作.
在其他时间段系统异常程度较低,监测系统使用较小的监测周期,因此CPU利用率要低于采用固定监测周期的方法.
在整个实验过程中,动态调整监测周期方法的总CPU利用率低于固定监测周期的方法,在系统运行状况相对稳定的时候这种优势更加明显.
不同监测方式对应的网络流量的对比分别如图9(d)所示,从图中可以看出,在错误注入的时间点,由于系统异常程度突然变高,动态调整监测周期的方法会通知监测系统立即采用较小的监测周期,因此动态调整监测周期的方法每分钟内发送的网络流量会呈现快速增长的趋势;当系统异常程度较低的时候,动态调整监测周期的方法使得监测系统逐渐采用较大的监测周期,数据收集次数减少,因此每分钟内发送的网络流量在不存在错误的时间段呈减少的趋势.
固定监测周期的方法每分钟内发送的网络流量不随错误的注入与消除产生较大的变化.
整个实验过程中,动态调整监测周期的方法发送的网络流量低于固定监测周期的方法.
4.
2.
5实例分析:内存泄露本节以表3中内存泄露故障为例,来分析与固定监测周期的方法相比,本文所提出方法在故障检测有效性、及时性以及监测开销方面的优势.
在实验中,根据经验本文将最大、最小监测周期分别设置为300秒、10秒.
最初系统异常值为0,则以最大监测周期300秒进行监测,本文在搜集到第30个监测数据后注入故障,由图10可以看到异常程度的变化,由图11可以看到监测周期动态调整情况.
(1)故障检测的有效性如图10所示,在第30个监测点注入故障后,由于内存泄露是逐渐严重的过程,异常程度总体上呈上升趋势,并且在第49个监测点达到了异常报警的条件(即连续10个点超过阈值0.
2).
因此,所提出方法能够有效的检测到所注入的内存泄露故障.
(2)故障检测的及时性:如图11所示,在故障注入后,系统异常程度不断增加,监测周期不断减小.
那么,从注入故障到检测到故障(监测点31-49)本文所提出的方法经历了1959秒.
对于传统固定周期的监测方法,如果设定监测周期为150秒(即最大监测周期的二分之一),获取同样数量的监测数据则需要经历2850秒.
因此,在系统出现异常的情况下,本文所提出方法所需要的检测时间为传统方法的68.
7%.
(3)监测开销比较:如图11所示,在未进行故障注入时,本文所提出方法的监测周期始终保持最大值,搜集监测数据量为传统固定周期监测方法的一半.
显然,在系统正常运行的情况下,本文所提出方法的监测开销为传统方法的50%.
在实验中,第1-30个监测点,系统处于正常运行状态,在第30个监测点注入错误,在第49个监测点达到了如(2)中定义的故障报警条图10内存泄露故障注入图11监测周期调整王焘等:一种基于自适应监测的云计算系统故障检测方法13件.
那么从第31到第49个监测点,共搜集19了监测点,经历了1959秒,而对于固定周期方法,这个期间搜集监测点的数量为14个,本文方法的监测开销为固定周期方法的135.
71%.
因此,本文方法监测开销在正常状态下为固定周期方法的50%,在故障状态下多于固定周期方法的35.
71%,以监测开销的提升换来了如(2)中分析的故障检测及时性提升31.
3%.
5相关工作本文的研究内容是提出一种自适应监测方法,根据云计算系统运行状态自适应动态调整监测对象和监测周期,以减少系统在正常运行状态的监测开销,并提高系统在异常状态的错误检测及时性.
论文面向的是云计算系统的监测,涉及到监测的两个要素:对象的选择和周期的调整.
对于前者,本文根据历史数据分析度量间的相关性从而选取反映系统运行状态的关键度量;对于后者,本文根据系统异常程度适应性动态调整监测周期,涉及到了系统异常程度评估方法以及监测周期调整策略两个方面.
由以上分析可以看出,本文涉及到的相关工作主要包括:面向云计算系统的监测框架、监测对象选择、系统异常程度评估和监测周期调整等四个方面.
因此,本章从以上各方面,分别介绍和比较了相关工作.
5.
1云计算系统监测框架当前面向云计算系统的监测框架通常采用中心式的,即在每个需要监测的主机或者虚拟机上部署代理程序(Agent),然后将监测数据搜集并存储到中心服务器,包括开源工具包括Zabbix,Nagios12,Ganglia13等,商业工具IBMTevoli14,HPOpenView15,LiveAction16等.
然而,大量监测数据的搜集和传输会带来巨大的监测开销,给中心节点带来巨大压力,近来一些工作研究了分布式架构.
文献[12]提出一种基于分布式监测器的分层监测架构,具有较强的可扩展性以应对大规模系统实时监测与分析需求.
为了应对该问题,文献[13]分析了在Nagios,http://www.
nagios.
org/Ganglia,http://ganglia.
info/Tivoli,http://www-03.
ibm.
com/software/products/en/tivosystautoformult/OpenView,http://www8.
hp.
com/us/en/software-solutions/operations-manager-infrastructure-monitoring/LiveAction,http://liveaction.
com/不同应用场景下,以推(Push)和拉(Pull)模式获取监测数据在效率方面的差别,提出了面向用户需求,结合推拉模式的检测模型以降低监测开销.
文献[14]提出一种采用点对点(P2P,Peer-to-Peer)可扩展弹性的分布式监测系统,可以动态的添加和删除需要监测的数据源,适应于不断变化的云计算环境.
本文所提出的方法可以整合到以上监测框架,通过在线分析目标节点的监测数据来故障检测,进而调整监测周期以减少开销.
近年来一些工作面向云计算环境的特定资源以及特定需求,提供了监控机制.
VMDriver是将感知VMM事件和构建VM语义相分离.
其通过Hypervisor搜集监测度量,与目标VM的类型和版本无关,可以监测所有GuestOS[15].
文献[16]采用REST形式以树形结构对云计算系统中的各种资源(如计算、网络、存储)进行建模,从而便于用户搜集.
文献[17]将监测数据以模型的形式进行刻画,根据用户对监测资源的关注点不同,为不同用户提供差异化视图.
mOSAIC面向不同云应用,为用户提供了获取可定制资源的监测接口[18].
MonPaaS区分云平台的服务提供者和消费者,使得云服务提供者能够看到完整的云框架,同时将监测作为一种服务提供给云服务消费者,使其能够自动看到其租用的云资源,并且定义其他所需要监测的对象[19].
本文所提出的方法通过调整监测对象和监测周期来减少监测开销,可以有机的整合到已有的云计算系统监测框架中.
5.
2监测对象选择监测系统通常为各监测对象设定约束条件,通过检测冲突来发现系统故障.
这种方式通常需要搜集网络中各节点的监测数据,聚集后统一处理(如计算SUM值),因而减少监测数据传输的通信开销成为重要问题.
许多工作将冲突条件分解到各个节点,对一定周期内某种事件发生的概率进行估计,调整局部的约束条件[20-22].
对于网络监测,通常采用采样的方式随机搜集部分监测数据,检测是否与预设条件相冲突[23].
在已有方法中,由于约束条件通常需要领域知识,系统管理员难以手工设定.
本文基于相关分析挖掘各度量间的相关性,通过监测部分关键度量就可以推断出整个系统的运行状态,监测对象根据历史数据自动选择,无需系统管理员根据系统的特定以及领域知识人为手工设定.
5.
3监测周期调整监测周期动态调整的工作并不多,与本文最为相关的14计算机学报2016年工作是文献[24].
作者为了减少通信开销,根据监测度量波动程度来调整监测周期,波动越大监测周期则调整的越短.
同时,监测周期调整简单的借鉴了TCP拥塞控制"缓慢开始,快速下降"的思想.
该方法存在两个问题:首先,在云计算环境下,负载量即客户请求的数量是在不断变化的,会相应造成度量波动,因此度量波动程度并不代表系统出现问题;其次,TCP拥塞控制的机制不能充分考虑到异常程度,周期调整幅度与异常程度变化不相适应.
本文利用PCA考虑各度量间的相关性来评估系统异常程度,而并不只是关注于某个度量,适用于负载动态变化的云计算环境.
同时,建立软件可靠性模型,根据对异常程度的评估以及故障出现时间的预测动态调整监测周期,使得周期调整幅度与异常程度变化相适应.
5.
4异常程度评估故障检测和预测技术通常对系统的日志或者监测数据进行分析以评估系统的异常程度.
LogMaster[25]解析日志文件,挖掘事件间的相关性,通过监测其变化来预测系统故障.
文献[26]利用贝叶斯网降维,同时利用信息熵和Euclidean距离来检测与其他节点行为不一致的节点.
为了及早避免故障的发生,一些工作引入了时间序列模型,通过对一些度量变化趋势的分析来预测故障.
文献[27]利用WilcoxRank-sum对监测数据进行趋势分析,以预测处理器资源利用情况.
文献[28]利用时间相关异常方法SIGs(Structure-of-InfluenceGraphs)来推断交互组件间的影响.
PCA技术由于具有较低的时间复杂度,环境适应性较好,也被用于系统管理.
文献[29]利用PCA和ICA进行特征提取,通过降维来减少需要分析的监测度量的数量,进而利用离群点检测来辨别集群系统中的故障节点.
该方法采用PCA对监测数据降维,而并不直接用来检测异常状态.
文献[30]结合源码分析与信息提取技术来解析日志以创建组合特征,由于同组特征向量中日志信息的各维度间存在高相关性,该方法利用PCA静态分析与检测相关系数偏离的日志信息.
已有方法通常采用较为复杂的统计学模型,具有较高的时间复杂度,不适合在线监测的场景.
同时,需要设定较为复杂的参数,这些参数随应用场景而变化,若不能选择合适的参数将会影响模型的准确性.
本文根据最近而非全部的监测数据,利用增量式PCA动态更新特征向量,并且基于余弦相似度而非距离来评估系统异常程度.
本文所提出的方法具有较低的计算复杂度,能够适应负载的动态变化,适用于在线评估系统异常程度.
6结论运行监测是云计算平台提供的一种重要基础服务,对于保障云计算系统性能与可靠性至关重要.
然而,频繁的搜集、传输、存储和分析海量监测数据会带来巨大性能开销以及云用户费用支出.
相反,如果监测周期过大,则降低了故障检测的及时性,且不能搜集足够的监测数据以供故障分析与定位.
因此,本文面向云计算系统,提供一种基于故障检测的自适应监测方法.
该方法考虑到了监测成本、监控需求、故障概率等因素.
监测成本是由监测对象和监测周期两个方面所决定的,本文提出了关键度量选择方法以选择监测对象,以及监测周期动态调整方法,根据故障发生的概率动态调整监测周期,从而达到了在低故障概率状态下具有较低监测开销,在高故障概率状态下具有较高检测及时性的监测要求.
在监测对象选择方面,利用相关分析计算度量间相似性以建立度量关联图,基于此从众多度量中选取反映系统运行状态的关键度量.
在监测周期调整方面,基于PCA分析主特征向量偏差程度以评估检测系统异常程度,进而结合可靠性模型动态调整监测周期.
实验结果表明,本文所提出的方法能够适应云环境下负载的动态变化,准确评估系统异常程度,自动调整监测频率以提高系统在异常状况下故障检测的准确性与及时性,同时降低系统在正常运行过程中的监测开销.
参考文献[1]D.
A.
Patterson.
Asimplewaytoestimatethecostofdowntime//Proceedingsofthe16thUSENIXConferenceonSystemAdministration.
Philadelphia,USA,2002:185-188.
[2]M.
C.
HuebscherandJ.
A.
McCann.
Asurveyofautonomiccomputing-degrees,models,andapplications.
ACMComputerSurveys,2008,40(3):1-28.
[3]G.
Jiang,H.
Chen,andK.
Yoshihira.
Modelingandtrackingoftransactionflowdynamicsforfaultdetectionincomplexsystems.
IEEETransactionsonDependableandSecureComputing,2006,3(4):312-326.
[4]M.
A.
MunawarandP.
A.
S.
Ward.
Acomparativestudyofpairwiseregressiontechniquesforproblemdetermination//ProceedingsoftheConferenceoftheCenterforAdvancedStudiesonCollaborativeResearch.
Toronto,Canada,2007:152-166.
[5]J.
D.
Evans,StraightforwardStatisticsfortheBehavioralSciences.
PacificGrove,CA,USA:Brooks/ColePubCo,2005.
[6]T.
Wang,J.
Wei,W.
Zhang,H.
Zhong,andT.
Huang.
Workload-awareanomalydetectionforwebapplications.
JournalofSystemsandSoftware,2014,89(1):19-32.
[7]T.
Wang,W.
Zhang,J.
Wei,H.
Zhong,andT.
Huang.
FD4C:automaticfaultdiagnosisframeworkforwebapplicationsincloudcomputing.
IEEETransactionsonSystems,ManandCybernetics:Systems,2016,46(1):61-75.
[8]A.
Williams,M.
Arlitt,C.
Williamson,andK.
Barker.
Webworkloadcharacterization:Tenyearslater.
Webcontentdelivery,2005,2(1):3-21.
[9]K.
Shibata,K.
Rinsaka,andT.
Dohi.
Metrics-based王焘等:一种基于自适应监测的云计算系统故障检测方法15softwarereliabilitymodelsusingnon-homogeneouspoissonprocesses//Proceedingsofthe17thInternationalSymposiumonSoftwareReliabilityEngineering.
Raleigh,NorthCarolina,2006:52-61.
[10]F.
Salfner,M.
Lenk,andM.
Malek.
Asurveyofonlinefailurepredictionmethods.
ACMComputerSurveys,2010,42(3):1-42.
[11]S.
PertetandP.
Narasimhan.
Causesoffailureinwebapplications.
ParallelDataLaboratory,CarnegieMellonUniversity,CMU-PDL-05-109,2005.
[12]M.
Andreolini,M.
Colajanni,andM.
Pietri.
Ascalablearchitectureforreal-timemonitoringoflargeinformationsystems//ProceedingsoftheSecondSymposiumonNetworkCloudComputingandApplications.
London,UK,2012:143-150.
[13]H.
HuangandL.
Wang.
acombinedpush-pullmodelforresourcemonitoringincloudcomputingenvironment//ProceedingsofIEEE3rdInternationalConferenceonCloudComputing.
Miami,USA,2010:260-267.
[14]B.
Konig,J.
M.
A.
Calero,andJ.
Kirschnick.
Elasticmonitoringframeworkforcloudinfrastructures.
IETCommunications,2012,6(6):1306-1315.
[15]G.
Xiang,H.
Jin,D.
Zou,X.
Zhang,S.
Wen,andF.
Zhao.
VMDriver:adriver-basedmonitoringmechanismforvirtualization//Proceedingsofthe29thIEEESymposiumonReliableDistributedSystems.
Delhi,India,2010:72-81.
[16]H.
Han,S.
Kim,H.
Jung,H.
Y.
Yeom,C.
Yoon,J.
Park,etal.
.
ARESTfulapproachtothemanagementofcloudinfrastructure//ProceedingsofIEEEInternationalConferenceonCloudComputing.
Bangalore,India,2009:139-142.
[17]J.
Shao,H.
Wei,Q.
Wang,andH.
Mei.
Aruntimemodelbasedmonitoringapproachforcloud//ProceedingsofIEEE3rdInternationalConferenceonCloudComputing.
Miami,USA,2010:313-320.
[18]M.
Rak,S.
Venticinque,M.
Txobhr,G.
Echevarria,etal.
Cloudapplicationmonitoring:themOSAICapproach//ProceedingsofIEEEThirdInternationalConferenceonCloudComputingTechnologyandScience.
Athens,Greece,2011:758-763.
[19]J.
M.
A.
CaleroandJ.
G.
Aguado.
MonPaaS:anadaptivemonitoringplatformasaserviceforcloudcomputinginfrastructuresandservices.
IEEETransactionsonServicesComputing,2015,8(1):65-78.
[20]S.
Kashyap,J.
Ramamirtham,R.
Rastogi,andP.
Shukla.
Efficientconstraintmonitoringusingadaptivethresholds//ProceedingsofIEEE24thInternationalConferenceonDataEngineering.
Cancún,México,2008:526-535.
[21]M.
DilmanandD.
Raz.
Efficientreactivemonitoring//ProceedingsoftheTwentiethAnnualJointConferenceonComputerCommunications.
Anchorage,USA.
2001:1012-1019.
[22]I.
Sharfman,A.
Schuster,andD.
Keren.
Ageometricapproachtomonitoringthresholdfunctionsoverdistributeddatastreams//ProceedingsofACMSIGMODinternationalconferenceonManagementofdata.
Chicago,IL,USA,2006:.
[23]C.
EstanandG.
Varghese.
Newdirectionsintrafficmeasurementandaccounting.
SIGCOMMComputerCommunicationsReview,2002,32(4):75-75.
[24]S.
MengandL.
Liu.
Enhancedmonitoring-as-a-serviceforeffectivecloudmanagement.
IEEETransactionsonComputers,2013,62(9):1705-1720.
[25]X.
Fu,R.
Ren,J.
Zhan,W.
Zhou,Z.
Jia,andG.
Lu.
LogMaster:miningeventcorrelationsinlogsoflarge-scaleclustersystems//ProceedingsofIEEE31stSymposiumonReliableDistributedSystems.
Irvine,USA,2012:71-80.
[26]Q.
Guan,D.
Smith,andS.
Fu.
Anomalydetectioninlarge-scalecoalitionclustersfordependabilityassurance//ProceedingsoftheInternationalConferenceonHighPerformanceComputing.
Goa,India,2010:1-10.
[27]F.
Salfner,P.
Troger,andS.
Tschirpke.
Cross-coreeventmonitoringforprocessorfailureprediction//ProceedingsoftheInternationalConferenceonHighPerformanceComputing&Simulation.
Leipzig,Germany,2009:67-73.
[28]A.
J.
Oliner,A.
V.
Kulkarni,andA.
Aiken.
Usingcorrelatedsurprisetoinfersharedinfluence//ProceedingsoftheIEEE/IFIPInternationalConferenceonDependableSystemsandNetworks.
Chicago,USA,2010:191-200.
[29]Z.
Lan,Z.
Zheng,andY.
Li.
Towardautomatedanomalyidentificationinlarge-scalesystems.
IEEETransactionsonParallelandDistributedSystems,2010,21(2):174-187.
[30]W.
Xu,L.
Huang,A.
Fox,D.
Patterson,andM.
I.
Jordan.
Detectinglarge-scalesystemproblemsbyminingconsolelogs//Proceedingsofthe22ndACMSIGOPSsymposiumonOperatingsystemsprinciples.
BigSky,USA.
2009:117-132.
16计算机学报2016年BackgroundMoreandmoreapplicationsaredeployedonpubliccloudcomputingplatformstoprovideservices.
Duetothecomplexity,dynamismandopennessofcloudcomputing,thedevelopmentanddeploymentofservicesarepronetomanytypesoffaults.
However,thefaultsinsideservicesareusuallytriggeredbycomplexfactorsinthedeploymentenvironmentatruntime.
Thismakesitdifficulttoreproducethefaults.
Therefore,debuggingandtestingservicescannoteffectivelyeliminatetheinevitablefaultstriggeredinspecificcontexts.
MonitoringisessentialtodetectanddiagnosefaultsforguaranteeingthereliabilityandperformanceofInternet-basedservices.
Monitoringtechnologiesforcloudcomputingsystemshavewidelyattractedtheattentionofindustrialandacademiccommunitiesinrecentyears.
Monitoringsystemsincloudcomputingcollectmetricsfrommultiplelayers(e.
g.
,network,hardware,virtualmachine,operatingsystem,middleware,andapplication)inheterogeneousnodes.
However,theprocedureofcollecting,transmitting,storingandprocessingalargeamountofmonitoringdataintroducessignificantoverhead,whichaffectsthesystemperformance.
Theexistingcommercialmonitoringsystems(e.
g.
,AmazonCloudWatch)andopensourcemonitoringsystems(e.
g.
,Zabbix)onlyprovideafixedmonitoringperiod.
Forexample,theycollectamonitoringdatainstanceeveryminute.
Moreover,thecustomersofcloudservicesalwayspayforthemonitoringserviceprovidedbyacloudserviceprovideraccordingtothecollectedmetricsandthefrequencyofcollectingmonitoringdata.
Amazonreportedthatthecostofmonitoringacloudapplicationoccupied18%oftheoperationcostforcustomers.
Customerscansavethemonitoringcostandreducetheperformanceoverheadbyreducingthemonitoreditemsandmonitoringfrequency.
However,monitoringwithfeweritemsandlowerfrequencydecreasesthevolumeofavailablemonitoringdatatodetectandlocatefaults,andthusdecreasesthepossibilityandtimelinessofdetectingfaults.
Toaddresstheaboveissue,thispaperproposesanadaptivemonitoringapproach,whichselectssignificantmetricsanddynamicallyadjuststhemonitoringperiodaccordingtothefaultprobability.
Formonitoreditems,weselectsomesignificantmetrics,whichcanrepresentothermetricsandreflectthesystemstatus.
Formonitoringfrequency,weincreasethemonitoringperiodtodecreasetheperformanceoverheadinthenormalsituation.
Onthecontrary,wedecreasethattoimprovethetimelinessandprecisionoffaultdetectionbycloselytrackingthesystemwhenthesystemiswithahighfaultprobability.
Sincethefaultprobabilityislowduringthewholesystemoperation,adjustingthemonitoringperioddynamicallycanreducealargeamountofmonitoringoverhead.
ThisworkwassupportedinpartbytheNationalNaturalScienceFoundationofChinaunderProject61402450andtheBeijingNaturalScienceFoundationunderProject4154088.
WANGTao,bornin1982,Ph.
D,assistantprofessor.
Hisresearchinterestsincludefaultdiagnosis,softwarereliability,andautonomiccomputingforcloudcomputingsystems.
GuZeyu,bornin1991,Master.
Hisresearchinterestisdistributedmonitoring.
ZHANGWen-bo,bornin1976,Ph.
D,professor.
Hisresearchinterestsincludedistributedcomputing,cloudcomputingandmiddleware.
XUJi-wei,bornin1985,Ph.
D.
Candidate.
HisresearchfieldisSoftwareEngineeringandNetworkDistributedComputing.
WEIJun,bornin1970,Ph.
D,professor.
Hisresearchinterestsincludeserviceorientedcomputing,middleware,andsoftwareengineering.
ZHONGHua,bornin1971,Ph.
D,professor.
Hisresearchinterestsincludesoftwareengineeringanddistributedcomputing.