APP下载

APDEX应用性能指标在保险行业的应用

2016-09-08昌盛李井波

中国新通信 2016年15期

昌盛 李井波

【摘要】 “互联网+”时代,传统保险公司越来越多地在互联网上构建相关交易服务,因此对保险应用运行状态进行实时监控与分析具有重要意义。本文介绍业界主流的APDEX应用性能指标,基于开源日志解决方案ELK搭建APDEX在保险行业的应用平台,为保险应用的运维和监控提供参考。

【关键词】 APDEX 应用性能指数 ELK 保险应用

The application performance indicators in the practice of the insurance industry based on APDEX

CHANG Sheng, LI Jingbo (China Life Insurance Co., Ltd. Shanghai Data Center, Shanghai, 201201, China)

Abstract:In the “Internet +” era, traditional insurance companies set up more and more related transaction services on the Internet. Its important to use real time monitoring and analysis of insurance application status. This paper introduces APDEX application performance index, which is a mainstream of industry. It builds up an APDEX platform applied in insurance industry, basing on ELK, an open source log solution. It contributes to operation and monitor on insurance application.

Key words:APDEX;Application Performance Index;ELK;Insurance Application

随着“互联网+”时代的到来,传统保险公司也越来越多地在互联网上构建相关交易服务[1]用户对于此类服务的响应时间有较为苛刻的要求,应用响应缓慢将极大妨碍用户体验,降低用户满意度,并导致系统用户的流失,为公司造成经营损失。因此,第一时间了解端到端的真实的用户体验,并将主观的体验量化显得尤为重要。本文通过对APDEX应用性能指标及其实现原理的介绍,阐述该指标在保险行业中的特殊应用及解决方案。

一、概述

1.1 APDEX介绍

APDEX(Application Performance Index)即“应用性能指标”,由众多企业及网络技术服务公司组成的APDEX联盟共同推出[2]。该指标是用户对应用性能满意度的量化值,它提供了一个统一的测量和报告用户体验的方法,在业界第一次将端到端的最终用户体验与应用性能联系在一起。

用户通过网络使用应用提供的各种交互服务,对于这些交互服务的质量评价,除了服务本身提供的内容质量外,服务响应时间的长短同样重要。若用户提交服务请求到服务请求的返回的时长超过一定时间,用户体验将受到一定程度的影响。APDEX指标制定的目的,就是将用户主观的体验转化为客观的指标,衡量和报告客户体验。

1.2 APDEX的优势

APDEX指标相对于传统的统计指标,有以下特点和优势:1、度量衡统一,指标不随测量单位的改变而改变。2、指标范围固定,在0到1之间浮动。3、直观易懂,0代表应用性能最差,1代表应用性能最好。4、 适用范围广,适用于任何可定义报告组的样本总和。5、指标唯一,使用唯一的指标来衡量相应应用报告组的质量。

二、实现原理

2.1定义报告组

报告组也叫统计区间,是指在一定时间、范围和测量方式内的测量样本集,是APDEX统计计算的数据基础。报告组一般有如下要求:

一定的时间范围。用于反映短时间内数据变化趋势的时间范围建议设定在15分钟之内,以5、10分钟为优;用于反映长时间内数据变化趋势的时间范围,建议根据具体情况进行分析,设定1日、7日、14日甚至更长时间。

一定的统计范围。为减少噪声干扰,提高统计精确度,统计范围应为对统计结果有积极意义的互不重复的相互独立的事件。如某WEB应用的前端事务的响应时长等。

一定的测量方式。测量方式应为统一,不建议将不同测量方式的测量结果纳入同一个报告组进行统计,防止因测量方式、测量精度的不通而造成最终报告组中数据的偏差。

2.2定义性能区间

服务响应时间的长短,直观地决定了用户的体验。通过定义不同的性能区间,可模拟用户的满意度,展现用户体验感受。根据用户满意度的高低,定义了三个性能区间,如下:

满意(Satisfied):用户可正常访问,对于该响应时长感到很满意。

可容忍(Tolerant):用户可勉强正常访问,虽然响应时长较长,但可以忍受。

失望(Disappointed):用户无法正常访问,响应时长很长,用户非常失望,决定放弃使用该服务。

以上的“满意”、“可容忍”、“失望”的性能区间,通过响应时长来划分。例如“满意”为0-2秒,“可容忍”为2-8秒,“不可容忍”为8秒以上。每两个性能区间的界限称为阈值(Threshold),简称“T”。因此,“满意”与“可容忍”之间阈值为T,“可容忍”与“失望”之间阈值为4T。三个区间使用阈值T表示为:

满意:[0-T)

可容忍:[T-4T)

失望:[4T-∞)

以上“[”代表大于等于,“)”代表小于。

对于不同应用和服务,用户的容忍能力不尽相同,因此不同应用的性能区间也有所不同,最直观的表现为T值的不同。对于每个应用T值的确定,将在以下章节详细介绍。

3.3统计样本数

通过定义性能区间,我们将报告组中的样本进行分类,将满足以上不同性能区间的样本分别计数。一般情况下,为满足统计需要,提高统计精确度,建议报告组中的样本数不少于50个。若样本较少,计算的结果将有很大的随机性,一般不具有实际的统计意义。

3.4计算APDEX值

3.5报告结果

根据以上公式,我们可以发现APDEX指标是一个0到1之间的数值。我们将计算得出的该数值与用户满意度进行关联,具体如下:

各数据后的下标“T”作为结果的一部分展现,例如当T=2时,APDEX=0.79时,最终展现的数据为0.792。

各满意度区间关联如下:

优秀(Excellent):[1.00-0.94)[T]

好(Good):[0.94-0.85) [T]

一般(Fair):[0.85-0.70) [T]

差(Poor):[0.70-0.50) [T]

不可接受(Unacceptable):[0.50-0.00] [T]

以上“[”代表大于等于,“]”代表小于等于,“)”代表小于。

三、Apdex应用性能指标在保险行业的应用

我们以ELK技术栈(ElasticSearch+Logstash+Kibana)为例,构建日志采集及分析系统,并对前端及中间件服务器的响应时长(Time-Taken)进行统计,计算并展现APDEX值。

3.1基于ELK技术栈的日志采集模型

ELK技术栈即ElasticSearch,Logstash,Kibana的简称。是一套开源、分布式的日志收集、聚合及展现工具[3]。其中,ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎,基于RESTful web接口;Logstash 是一个应用程序日志、事件的传输、处理、管理和搜索的平台。可用于对应用程序日志进行收集管理,提供Web接口用于查询和统计;Kibana 是一个为 Logstash 和 ElasticSearch 提供的日志分析的Web平台,可用于对日志进行高效的搜索、可视化、分析等各种操作。

为提升Logstash采集日志信息的吞吐量,我们在Logstash Shipper和Logstash Indexer中增加了Redis作为异步队列,用以降低业务高峰期产生的排队现象,提升日志采集的吞吐量。

系统架构如下:

4.2前端日志改造

获取应用性能数据的方式有很多,这里重点介绍通过上文搭建的ELK日志采集及分析平台,获取前端WebLogic Server应用系统性能数据。WebLogic Server是美国Oracle公司出品的基于JAVAEE架构的中间件Java服务器,可用于开发、集成、部署和管理大型分布式Web应用、网络应用和数据库应用。

WebLogic Server默认的Access Log不包含交易时间,无法用于性能分析,因此需要进行相应的日志改造。改造根据W3C规范,我们将WebLogic Server的Access Log改造成如下格式:

date time c-ip cs-method cs-uri time-taken sc-status bytes定义如下:

date:事务完成的日期

time:事务完成的时间

c-ip:客户端IP地址

cs-method:请求的方法,如GET或POST

cs-uri:请求的完整URI

time-taken:完成交易需要的时间,单位为秒

sc-status:响应状态码,如404

bytes:事务传输的字节数,单位为字节

4.3基于3sigma的T值确定方式

如上一章节所述,对于不同应用和服务,用户的容忍能力不尽相同,因此不同应用的性能区间也有所不同。因此,有必要针对不同的应用设计不同的性能区间,也就是不同的T值。

自定义T值的方法有很多,可以根据经验确定,或通过不断收敛判断确定等。本文介绍一种通过3Sigma确定T值的方法,该方法可无需人工介入和多次收敛,通过自动计算方式确定最适合的T值,减少人工运维压力,提高系统运行效率。

根据对现有保险应用的梳理,归纳出以下三点假设:

各应用由若干服务组成,一般每个应用包含不少于10个服务;

服务在大多数的时间内运行稳定。响应时间满足正态分布;

用户可接受的最长服务响应时长为2s-8s,如果超过8s则认为服务较差,用户无法容忍。

根据以上假设,我们确定T值有如下特点:

T值将兼顾各服务的性能及稳定性;

T值将参考目前系统的运行现状;

通过定义T来进行服务治理,并逐步降低服务的平均响应时间,最终提高应用的整体性能

因此,T值可定义为:

其中,μ,δ分别为该应用所有服务在过去的45天内的响应时长的均值和标准差。

我们知道,μ+3δ可以保证99.7%的样本落入[0,μ+3δ],如果服务运行稳定并令μ+3δ小于2s,则能保证APDEX指标趋向于1.00[T],使应用服务水平不断提高。为使公式更具有通用性并可自动定义相关参数,以上模型内的2s和8s可使用以下公式代替,最终模型为:

其中,a为{μi+3δi}的50分位数,取b为{μi+3δi}的99分位数[4]。{μi+3δi}为该应用各服务响应时长的均值加上三倍方差的集合。

五、结束语

保险行业的应用有其独特之处,结合保险行业的业务应用情况,采用ELK技术栈计算APDEX指标,可实时模拟用户体验,快速确定系统故障,提出优化建议。对用户体验的持续优化起到积极作用。随着业务模式的改变和系统架构的调整,APDEX指标和T值的计算方式也不会一成不变,而将持续更新和优化。

参 考 文 献

[1] 林珊珊. 保险应用系统的若干模式[J]. [2007]. 中国金融电脑

[2] Chris Loosley. How Apdex Works[EB/OL]. [2010-09-16]. http://www.apdex.org/index.php/category/how-apdex-works/

[3] Kimchy. ntrudution of ElasticSearch[EB/OL]. [2015-04-29]. https://www.elastic.co/products/elasticsearch

[4] 盛骤. 概率论与数理统计(第四版)[M]. [2010.10.01]. 高等教育出版社