基于服务的云平台应用程序监控分析系统①

罗理机,唐 华,周 昕,张 涛

(湖北工业大学 信息技术中心,武汉 430068)

随着云计算技术的发展与市场规模的扩大,越来越多的企业建立了云平台为应用程序提供统一的资源池和通用的平台组件服务. 由于云平台组件的通用性,极大地便利了应用程序的规模部署[1].

对于应用程序开发者和云平台运维人员而言,最为关注的是应用程序与云平台的兼容性,他们希望实时检测应用程序的运行情况并及时发现异常和定位原因,以便于进行针对性的调整[2]. 因此,收集云平台上应用程序的运行数据和分析异常原因的能力变得尤为重要.

云平台的架构包含3 个基本层次: 基础设施层(infrastructure layer)、平台层(platform layer)和应用层(application layer)[3]. 基础设施层是最底层,提供标准化的硬件资源池服务. 中间的平台层为应用程序的开发、测试、部署和运行提供相关的中间件和基础服务.应用层是最高层,提供种类繁多的应用程序集合. 云平台为了给用户提供通用便捷的组件服务,相比于传统的服务器架构来说底层更为封闭,并且多层架构的云平台也成为了主流,以上两点因素都增加了对其中应用程序运行数据的收集和分析的难度[4]. 目前,云平台上的应用程序监控主要面临以下问题: (1)应用程序权限限制. 大多数云平台自身不具备应用程序级别的性能监控能力,主要依赖于应用程序自身的检测异常机制和第三方检测软件的支持. 因此,云平台运维人员必须赋予应用程序足够的权限,这大幅度增加了云平台的运维成本和安全风险[5]. (2)全流程收集分析异常能力不足. 云平台的组件服务对调用它的应用程序是不透明的,这使得应用程序很难识别造成异常的根本原因. 并且,随着大型企业云的层次结构变得愈发复杂[6],每一层中多种交互组件服务的存在加大了准确判断性能异常原因的难度[7]. 提高快速准确查明异常原因的能力,需要在云平台的不同层进行收集和关联异常信息,建立全流程收集分析异常的能力. (3)监控程序自定义能力不足. 目前,一些大型的云平台已经具备对在其中运行的应用程序进行监控的能力,但这些方法大多是对应用程序的进程状态信息做简单分析,并传送给云平台运维人员做人工巡检. 然而,为满足不同应用程序的监控需求,需要对监控系统的信息采集速率、采样数据量和性能异常阈值等指标进行自定义设置,而不能仅仅依赖于操作系统进程表中的数据. 对云平台用户和运维来说,提供对应用程序多样化的监控需求是十分迫切的,建立适配性强的云平台应用程序性能监控系统已经成为一项重要的研究课题[8].

为了解决以上问题,本文设计了一种针对云平台应用程序的性能监控系统,可以跨层收集应用程序的运行时数据,快速准确的识别导致应用程序异常的云服务组件. 系统的主要特性有: (1)具有完备的云平台应用程序监控运维能力. 能够全层次收集并分析云平台上应用程序的运行数据,并利用平台即服务(platform as a service,PaaS)提供的管理服务接口(management service interface,MSI)实现自动运维. (2)具有快速准确的异常检测能力. 通过对平台服务调用的持续时间分析,识别异常调用事件,为不同应用程序设置自定义的异常事件指标值,保证了异常检测的准确性. (3)提供云平台组件层面的瓶颈识别功能. 通过对应用程序调用组件的时间值进行异常偏离判断,系统能够识别引发瓶颈的云平台服务组件. 综上所述,本文构建了一个在私有云平台中基于服务组件的应用程序异常检测和瓶颈识别系统,适用于多层架构云平台上的应用程序监控分析. 提供该能力有助于增强云平台运维人员对平台资源的管控能力,降低应用程序开发人员对程序代码检测的压力,进一步推动了云平台资源使用的合理化.

1 相关研究

现有关于云平台系统资源或应用程序运行性能监控与分析的研究,主要途径是通过在不连续的时间间隔内收集重要的性能指标数据,并进行分类、聚类、统计等异常检测分析. 在此基础上建立的异常监控分析系统框架,一定程度上保证了云平台的性能、可靠性和服务质量.

文献[9]中提出了一种称为云平台自动异常检测(autonomic anomaly detection,AAD)的系统框架,通过特征提取和数据变换整理性能指标数据,并对异常事件进行聚类分析,实现了异常事件的自动监控与分析.在此基础上,文献[10]引入互信息(mutual information,MI)参数来降低不同性能指标之间的冗余,使性能指标数据的特征提取更为精确. 然后采用主成分分析法(principal component analysis,PCA)对提取的数据降维,最后采用决策树分析性能指标从而识别异常事件. 饶翔等[11,12]提取云平台的日志信息构造故障特征模型,关联时间窗口内外的异常事件,并采用改进的决策树训练基于日志信息的故障分类器,实现了前后异常事件的关系判断. 但是,该模型只针对的是系统的日志信息,要求云平台对日志进行分类并使用标准语义记录,故障分类器需要大量的日志信息进行分析,所需的时间成本和存储空间较大. 贾统等[13]提出通过提取日志模板变量,构建日志异常检测模型,然后使用机器学习、聚类等方法识别异常数据,并对异常事件预警.

然而,以上方法均利用获取云平台底层运行数据(例如虚拟机日志信息)或检测应用程序代码来实现对云平台资源的监控与分析,虽取得了较多成果,但已难以适应当前部署应用程序数量剧增和底层愈加封闭的主流大型云平台(例如PaaS)的要求.

现有的云服务提供商提供的资源监测服务(例如亚马逊云CloudWatch[14],阿里云CloudMonitor[15]以及华为云监控服务[16]等)通过在云平台底层添加数据采集器,监控底层云资源,然后在开发测试环境中执行并检测应用程序代码,实现了对云资源和应用程序的有效监控. 但是,开发测试环境中的检测结果并不一定总是能适用于实际的生产环境,并且云平台的底层数据隐藏在对外提供的托管服务层之下,接口不对外开放[17,18],适用范围有限.

在以上研究基础上,本文设计了一种基于云平台服务组件的应用程序异常检测和瓶颈识别系统. 通过跨层关联和分析服务调用请求数据,识别导致应用程序异常的云服务组件,实时准确地判断异常原因.

2 云平台异常检测和瓶颈识别系统模块设计

系统设计的主体思想是利用对应用程序调用云平台组件响应时间的实时监控,为云平台的运行维护人员提供一个集成应用程序性能检测、平台组件异常检测和异常问题定位功能的云平台监控分析整体解决方案. 系统通过嵌入云平台的内置服务收集应用程序与云平台的组件交互数据,并且对数据进行储存和分析.获得的分析结果根据不同需求分别反馈给云平台管理员和程序开发人员. 系统通过监控云平台组件的响应时间,对云平台的整体性能进行分析,并且对单个应用程序的异常响应情况做出即时反应,避免了传统云平台监控系统利用应用程序监听器对应用程序进行监控的弊端[19]. 同时,对不同类型云组件响应时间的分析可以快速、准确地定位产生异常问题的原因.

云平台监控分析系统以应用程序调用服务组件的响应时间为指标识别和描述应用程序的异常响应,并以此为基础搭建整体功能框架. 首先,设计一种自动识别异常响应的检测器,以建立应用程序异常与监控事件分析的触发机制; 然后,提出了应用程序工作负载变化监控方法,以识别应用程序异常响应是由于工作负载变化还是云平台组件瓶颈引发; 最后,对于非应用程序工作负载变化引发的异常响应,提供了云平台组件瓶颈识别功能.

2.1 系统框架

图1 给出了私有云环境下云平台监控分析系统的整体架构,分为数据收集、异常检测和异常分析3 个模块. 数据收集模块用标识符对相关联的用户请求进行标记,并负责在云平台的每一层上收集有关应用程序调用的信息; 异常检测模块把收集到的模块存入数据库中,进行数据分析判断是否需要启动异常分析; 异常分析模块负责分析异常事件发生的原因并识别造成性能瓶颈异常的原因. 本节余下的部分将对云平台监控分析系统架构中的每一模块的功能进行详细说明.

图1 云平台监控分析系统架构

2.2 前端数据收集模块

云平台的多层架构使用户能够以按需、易扩展的方式获得所需的资源,同时也提高了云平台的安全性.在云平台的每一层只能收集与其本层状态变化相关的数据,且层次之间的封装结构使其中一层无法监测到其他层的状态更改. 因为应用程序调用组件的行为跨越云平台的多个层次,所以为了对云平台的系统资源进行整体监控,系统必须从每个层次收集数据,并把与同一调用行为相关联的数据进行跨层组合.

为了解决这个问题,云平台监控分析系统在前端设置了数据收集模块. 数据收集模块通过在服务接口的入口拦截内核调用来收集应用程序的组件调用请求数据. 具体的做法是首先在每一个HTTP 请求的消息头中添加唯一的数据标识符,使云平台的每一层都能够识别请求的关联对象. 然后,把数据收集工具部署到平台内,抓取组件调用请求并根据消息头中的数据标识符关联与之相关的应用程序和平台组件. 最后,数据收集模块组合调用请求并记录与之相关的资源变化信息,再根据需要对不同的信息分类保存. 组合后的信息记录使系统能够跨层监控应用程序对平台组件的请求调用,以及与之相关联的资源变化信息,而不需要考虑云平台各层之间的耦合关系. 同时,不同调用请求对应的数据收集工具相对独立,互相之间无须发送关联消息,因此也提高了模块的扩展性.

2.3 异常检测模块

系统收集到组合信息之后,以应用程序ID、时间为索引将其存入数据库中,便于长期存储和查询. 异常检测模块读取这些数据并进行定时分析. 模块对每个应用程序配置定制化的异常检测方法,不同应用程序可以对应不同的检测方法. 不同种类应用程序调用的平台组件服务类型、频率不同,因此其所适配的异常检测方法也不同. 为了解决应用程序和对应检测方法的适配问题,模块还支持对同一应用程序进行并发检测,从而比较不同检测方法的准确性,找出与应用程序匹配度最高的检测方法进行配置.

传统方式监控云平台性能往往是直接在云平台基础设施层部署采集插件,通过分析系统吞吐量、储存设备读写速度、CPU 时钟频率等指标达到监控云主机性能的目的[11–13],但这种方式已不能适用于目前主流的封闭底层资源监控接口的大型云平台. 异常检测模块通过调用平台层提供的服务响应接口分析云平台对应用请求的回应速度,来衡量云平台对请求的响应快慢,系统无须获取云平台底层的资源监控权限即可达到监控云平台性能的目的,提高了系统的通用性和安全性. 具体做法是当应用程序启动时,异常检测模块同时启动检测过程,该过程定期测量目标应用程序的响应时间Tresp和性能异常偏离率Ppad两个指标.

应用程序的响应时间用来衡量程序的性能,响应时间越长,性能越低,可以用以下公式表示:

其中,tri和tsi分别为第i个组件调用的服务回应时间和触发时间,n为统计持续时间内检测到的组件调用总个数.

为了衡量云组件服务对调用的响应快慢,我们还定义了性能异常偏离率指标,用来反映应用程序响应时间落在正常范围以外的概率. 当第i个组件调用的响应时间高于应用程序响应时间Tresp与统计持续时间内组件调用响应时间的标准差σresp之和时,组件调用响应时间被判定为偏离正常范围. 因此,性能异常偏离率Ppad可通过统计持续时间内偏离正常范围的组件调用数目Ndev和组件调用的总数Ntotal比例计算得到:

当Ppad大于5%时,表示在统计持续时间内有5%以上的组件调用响应时间偏离了正常范围,则此时异常检测模块认为应用程序性能发生异常.

为减少对应用程序的性能损耗,异常检测模块间隔启动对响应时间Tresp和性能异常偏离率Ppad两项指标的计算和分析,当Ppad偏离正常范围时,就触发异常事件.

异常检测模块也能够对应用程序匹配的检测方法进行分析间隔时间和统计持续时间两个参数的配置,其中分析间隔时间即为检测方法定时启动分析的间隔时间,这个参数在系统测试中被设置为15 s. 统计持续时间指检测方法提取和统计异常事件发生的时间跨度,通常时间跨度越长则内存中存放的数据量越大,为限制系统运行时占用的内存大小,统计持续时间参数在系统测试中被设置为30 min.

2.4 异常分析模块

异常分析模块对异常检测模块发出的异常事件进行分析,首先分析异常事件的发生原因,如果是由工作负载大小变化引起,则不做处理,如果是则进行瓶颈识别.

系统使用变点检测算法(change point detection,CPD)[20]对工作负载的变化进行检测,算法生成一个负载变化的变点列表来表示一段时间内工作负载的重大变化. 系统利用CPD 对负载变化点的历史数据批量分析,实现对平台负载变化的持久跟踪,能够准确识别平稳的大数据量请求(非峰值请求)造成服务器性能异常的情况.

对于因非工作负载变化而引起的性能异常,系统对其进行瓶颈识别,找出与之关联最大的平台组件. 系统首先记录每一次样本程序调用平台组件的时间长度组成数组C[n] (n为调用平台组件次数),然后使用离群值统计法[21]判断捕获的数据是否异常,此方法适用于在定时采集时间样本的数据量范围内对样本的偏离情况进行测算,计算出样本的偏离值. 系统选择与偏离值最大的时间样本相关联的组件作为瓶颈识别的结果,此组件即为引发瓶颈的云平台服务组件.

3 云平台应用程序监控分析系统测试

系统测试在OpenStack 私有云环境下进行,操作系统版本为CentOS 7.4,测试节点配置为8 核CPU (时钟频率2.6 GHz),16 GB 内存,200 GB 硬盘.

本次测试使用的样本应用程序是一个利用PHP 编写的Web 应用程序,功能是实现单点登录并发布图文信息. 程序调用统一身份认证(CAS)组件来实现身份验证,并调用云平台的数据存储组件来保存发布的信息. 用户的每次发布请求都会调用两次云平台服务组件,一次用于检查用户的登录状态,另一次用于在数据库相应表中写入数据.

为了全面评测云平台应用程序监控分析系统各个模块的功能,依次测试了系统检测云平台异常事件的能力、分析服务器负载变化的能力以及识别性能瓶颈原因的能力.

3.1 异常事件检测

在测试系统的异常事件检测能力之前,需要先确定样本程序正常运行时的响应时间. 因此,样本程序首先在无任何外部程序干扰的情况下运行了10 次,每次持续1 h,得到正常情况下样本程序响应时间的平均值tavg和标准差 σt. 响应时间的阈值tmax由以下公式获得:

利用操作系统的Page Cache 策略,写入8 线程单次4 KB 的Buffer,可以模拟云平台数据存储组件响应缓慢造成的性能异常. 设置此性能异常事件30 分钟触发一次,并在5 s 时间内调用平台的数据存储组件使响应时间升高到tmax以上,响应时间超过tmax则视为发生一次异常事件.

为验证第2.3 节所述系统异常检测模块的性能,将分析间隔时间设置为15 s,统计持续时间为30 min,样本程序的运行时间一共为5 h. 触发性能异常事件与系统检测到异常事件的时间点如表1 所示.

表1 触发和检测到异常的间隔时间统计

综合实验结果,从性能异常事件发生开始到系统检测到异常事件,平均用时268 s,最长的时间间隔为299 s. 由于检测用时与分析间隔时间密切相关,因此可以通过修改检测工具的分析间隔时间进一步对检测性能进行调优.

3.2 分析负载变化

在对系统的分析负载变化能力进行测试的过程中,样本程序同样运行5 个小时. 程序运行期间,更改高频读取请求的间隔时间为随机,以达到模拟平台负载变化的目的. 在随机高频读取请求发生期间,请求的频率在每分钟450–650 次之间,这远高于平台正常运行情况下每分钟120–150 次的请求频率,这些读取请求大部分都无法命中数据库缓冲区,因此会引发平台服务器缓存负载的急剧上升.

如图2 所示,每个负载高峰发生之后,系统几乎都能准确的检测到异常事件发生,纵向箭头指示检测到异常事件发生并触发瓶颈识别模块的时刻. 唯一一次例外是发生在两次高频请求短时间内集聚发生,这是由于系统在检测到第一次异常事件之后对数据进行回收处理,进入等待状态以收集更多数据. 在紧接着另一次发生负载高峰情况时,系统认为异常事件的发生是由于工作负载变化引起的,因此没有第二次触发瓶颈识别模块工作.

图2 服务器负载与异常检测能力测试

3.3 性能瓶颈原因识别

在第3.2 节的实验中,系统分析所有检测到的异常都是由云平台数据存储组件响应超时引起的. 实验结果符合实际情况,因为实验中的每一次异常事件都是由大数据量的Buffer 写入造成数据存储组件无法及时响应.

为了测试系统对其他原因引起性能瓶颈的识别能力,接下来本实验修改用户验证组件的逻辑,使应用程序向用户验证组件发送请求时,组件延迟返回消息,延迟时间大于tmax时,则产生异常事件. 在实验中设置每30 min 触发一次验证异常,实验共持续5 h.

如图3 所示,系统在每一次的逻辑异常发生之后都检测到了性能异常事件,其中7 次异常被系统识别为用户验证组件超时引发的异常,另外还有两次异常被识别为由数据储存组件超时引发. 通过手动检查云平台系统日志发现,例外的两次异常都是由于数据库查询超时引起用户验证组件异常,系统将异常归结为第一个出现异常的数据储存组件是准确的.

图3 识别异常事件原因能力测试

为了在更大的样本情况下测试多种异常组合发生时瓶颈识别的能力,系统在私有云平台上运行了1 个星期. 通过分析这段时间内系统检出的125 个异常,发现除了7 个异常事件外,大多数情况下系统都能准确识别第一个引起异常的平台组件,平台的瓶颈识别准确率达到了94.4%.

3.4 实验结果分析

在异常检测和瓶颈识别实验的基础上,测试云平台应用程序监控分析系统的通用性和准确性. 将系统的瓶颈识别准确率、是否需要平台底层监控权限、适用的云平台类型这3 项指标作为考察系统通用性和准确性的因素,对比算法是ATAD[22],vPerfGuard[23],BAD[24],ANN[25]. 为了更好地说明异常识别的性能,测试时采用了相同的引发云平台性能异常机制. 利用统一身份认证(CAS)组件仿真大量的随机读取请求发送至被测平台,持续时间均为1 个星期,结果如表2 所示,可以看出vPerfGuard 的识别准确率最高,而AAD-PSC次之,然后是BAD,其余算法的准确率较低. vPerfGuard的识别准确率高的原因是直接在云平台底层获取硬件资源和工作负载指标,避免了性能异常集聚发生时的误判,但是vPerfGuard 需要云平台提供底层的资源监控权限,无法适用于PaaS 类型的云平台,通用性不及其他方法. BAD 构建自适应的监督学习任务,识别准确率依赖大数据集的收集和模型拟合,AAD-PSC 是通过直接监测云平台的服务性能指标判断云平台的当前性能,所以AAD-PSC 比BAD 的判断准确率更高.

表2 触发和检测到异常的间隔时间统计

4 小结

监控和分析云平台上托管的应用程序运行情况是云平台运维中的一项核心需求,应用程序开发和云平台运维人员希望能够具备监控云应用程序的性能异常,并分析其产生原因的能力. 但随着云计算技术的发展,云平台的规模急速扩大,多层架构日益复杂,传统云平台应用程序监控系统存在依赖云平台赋权、异常溯源不准确、分析方式单一等问题,已无法满足现有大规模云平台的需求. 本文设计并实现了一种面向云平台应用程序的性能监控系统. 通过标识符跨层关联应用程序请求与相关事件,简化了信息收集过程. 采用了基于变点检测的瓶颈识别方法,实现了快速、准确的异常事件溯源. 实验结果表明,监控系统可以在异常事件发生后的5 min 内准确检测不同类别的异常事件并识别性能瓶颈,能够满足云平台下对应用程序运行性能的监控需求.

增强出版

本文附有基于服务的云平台应用程序监控分析系统演示视频,可点击视频链接或手机扫描二维码观看.