APDEX應用性能指標在保險行業(yè)的應用

昌盛 李井波

【摘要】 “互聯網+”時代，傳統(tǒng)保險公司越來越多地在互聯網上構建相關交易服務，因此對保險應用運行狀態(tài)進行實時監(jiān)控與分析具有重要意義。本文介紹業(yè)界主流的APDEX應用性能指標，基于開源日志解決方案ELK搭建APDEX在保險行業(yè)的應用平臺，為保險應用的運維和監(jiān)控提供參考。

【關鍵詞】 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

隨著“互聯網+”時代的到來，傳統(tǒng)保險公司也越來越多地在互聯網上構建相關交易服務[1]用戶對于此類服務的響應時間有較為苛刻的要求，應用響應緩慢將極大妨礙用戶體驗，降低用戶滿意度，并導致系統(tǒng)用戶的流失，為公司造成經營損失。因此，第一時間了解端到端的真實的用戶體驗，并將主觀的體驗量化顯得尤為重要。本文通過對APDEX應用性能指標及其實現原理的介紹，闡述該指標在保險行業(yè)中的特殊應用及解決方案。

一、概述

1.1 APDEX介紹

APDEX（Application Performance Index）即“應用性能指標”，由眾多企業(yè)及網絡技術服務公司組成的APDEX聯盟共同推出[2]。該指標是用戶對應用性能滿意度的量化值，它提供了一個統(tǒng)一的測量和報告用戶體驗的方法，在業(yè)界第一次將端到端的最終用戶體驗與應用性能聯系在一起。

用戶通過網絡使用應用提供的各種交互服務，對于這些交互服務的質量評價，除了服務本身提供的內容質量外，服務響應時間的長短同樣重要。若用戶提交服務請求到服務請求的返回的時長超過一定時間，用戶體驗將受到一定程度的影響。APDEX指標制定的目的，就是將用戶主觀的體驗轉化為客觀的指標，衡量和報告客戶體驗。

1.2 APDEX的優(yōu)勢

APDEX指標相對于傳統(tǒng)的統(tǒng)計指標，有以下特點和優(yōu)勢：1、度量衡統(tǒng)一，指標不隨測量單位的改變而改變。2、指標范圍固定，在0到1之間浮動。3、直觀易懂，0代表應用性能最差，1代表應用性能最好。4、 適用范圍廣，適用于任何可定義報告組的樣本總和。5、指標唯一，使用唯一的指標來衡量相應應用報告組的質量。

二、實現原理

2.1定義報告組

報告組也叫統(tǒng)計區(qū)間，是指在一定時間、范圍和測量方式內的測量樣本集，是APDEX統(tǒng)計計算的數據基礎。報告組一般有如下要求：

一定的時間范圍。用于反映短時間內數據變化趨勢的時間范圍建議設定在15分鐘之內，以5、10分鐘為優(yōu)；用于反映長時間內數據變化趨勢的時間范圍，建議根據具體情況進行分析，設定1日、7日、14日甚至更長時間。

一定的統(tǒng)計范圍。為減少噪聲干擾，提高統(tǒng)計精確度，統(tǒng)計范圍應為對統(tǒng)計結果有積極意義的互不重復的相互獨立的事件。如某WEB應用的前端事務的響應時長等。

一定的測量方式。測量方式應為統(tǒng)一，不建議將不同測量方式的測量結果納入同一個報告組進行統(tǒng)計，防止因測量方式、測量精度的不通而造成最終報告組中數據的偏差。

2.2定義性能區(qū)間

服務響應時間的長短，直觀地決定了用戶的體驗。通過定義不同的性能區(qū)間，可模擬用戶的滿意度，展現用戶體驗感受。根據用戶滿意度的高低，定義了三個性能區(qū)間，如下：

滿意（Satisfied）：用戶可正常訪問，對于該響應時長感到很滿意。

可容忍（Tolerant）：用戶可勉強正常訪問，雖然響應時長較長，但可以忍受。

失望（Disappointed）：用戶無法正常訪問，響應時長很長，用戶非常失望，決定放棄使用該服務。

以上的“滿意”、“可容忍”、“失望”的性能區(qū)間，通過響應時長來劃分。例如“滿意”為0-2秒，“可容忍”為2-8秒，“不可容忍”為8秒以上。每兩個性能區(qū)間的界限稱為閾值（Threshold），簡稱“T”。因此，“滿意”與“可容忍”之間閾值為T，“可容忍”與“失望”之間閾值為4T。三個區(qū)間使用閾值T表示為：

滿意：[0-T）

可容忍：[T-4T）

失望：[4T-∞）

以上“[”代表大于等于，“）”代表小于。

對于不同應用和服務，用戶的容忍能力不盡相同，因此不同應用的性能區(qū)間也有所不同，最直觀的表現為T值的不同。對于每個應用T值的確定，將在以下章節(jié)詳細介紹。

3.3統(tǒng)計樣本數

通過定義性能區(qū)間，我們將報告組中的樣本進行分類，將滿足以上不同性能區(qū)間的樣本分別計數。一般情況下，為滿足統(tǒng)計需要，提高統(tǒng)計精確度，建議報告組中的樣本數不少于50個。若樣本較少，計算的結果將有很大的隨機性，一般不具有實際的統(tǒng)計意義。

3.4計算APDEX值

3.5報告結果

根據以上公式，我們可以發(fā)現APDEX指標是一個0到1之間的數值。我們將計算得出的該數值與用戶滿意度進行關聯，具體如下：

各數據后的下標“T”作為結果的一部分展現，例如當T=2時，APDEX=0.79時，最終展現的數據為0.792。

各滿意度區(qū)間關聯如下：

優(yōu)秀（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應用性能指標在保險行業(yè)的應用

我們以ELK技術棧（ElasticSearch+Logstash+Kibana）為例，構建日志采集及分析系統(tǒng)，并對前端及中間件服務器的響應時長（Time-Taken）進行統(tǒng)計，計算并展現APDEX值。

3.1基于ELK技術棧的日志采集模型

ELK技術棧即ElasticSearch，Logstash，Kibana的簡稱。是一套開源、分布式的日志收集、聚合及展現工具[3]。其中，ElasticSearch是一個基于Lucene的搜索服務器。它提供了一個分布式多用戶能力的全文搜索引擎，基于RESTful web接口；Logstash 是一個應用程序日志、事件的傳輸、處理、管理和搜索的平臺?？捎糜趯贸绦蛉罩具M行收集管理，提供Web接口用于查詢和統(tǒng)計；Kibana 是一個為 Logstash 和 ElasticSearch 提供的日志分析的Web平臺，可用于對日志進行高效的搜索、可視化、分析等各種操作。

為提升Logstash采集日志信息的吞吐量，我們在Logstash Shipper和Logstash Indexer中增加了Redis作為異步隊列，用以降低業(yè)務高峰期產生的排隊現象，提升日志采集的吞吐量。

系統(tǒng)架構如下：

4.2前端日志改造

獲取應用性能數據的方式有很多，這里重點介紹通過上文搭建的ELK日志采集及分析平臺，獲取前端WebLogic Server應用系統(tǒng)性能數據。WebLogic Server是美國Oracle公司出品的基于JAVAEE架構的中間件Java服務器，可用于開發(fā)、集成、部署和管理大型分布式Web應用、網絡應用和數據庫應用。

WebLogic Server默認的Access Log不包含交易時間，無法用于性能分析，因此需要進行相應的日志改造。改造根據W3C規(guī)范，我們將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：響應狀態(tài)碼，如404

bytes：事務傳輸的字節(jié)數，單位為字節(jié)

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

如上一章節(jié)所述，對于不同應用和服務，用戶的容忍能力不盡相同，因此不同應用的性能區(qū)間也有所不同。因此，有必要針對不同的應用設計不同的性能區(qū)間，也就是不同的T值。

自定義T值的方法有很多，可以根據經驗確定，或通過不斷收斂判斷確定等。本文介紹一種通過3Sigma確定T值的方法，該方法可無需人工介入和多次收斂，通過自動計算方式確定最適合的T值，減少人工運維壓力，提高系統(tǒng)運行效率。

根據對現有保險應用的梳理，歸納出以下三點假設：

各應用由若干服務組成，一般每個應用包含不少于10個服務；

服務在大多數的時間內運行穩(wěn)定。響應時間滿足正態(tài)分布；

用戶可接受的最長服務響應時長為2s-8s，如果超過8s則認為服務較差，用戶無法容忍。

根據以上假設，我們確定T值有如下特點：

T值將兼顧各服務的性能及穩(wěn)定性；

T值將參考目前系統(tǒng)的運行現狀；

通過定義T來進行服務治理，并逐步降低服務的平均響應時間，最終提高應用的整體性能

因此，T值可定義為：

其中，μ，δ分別為該應用所有服務在過去的45天內的響應時長的均值和標準差。

我們知道，μ+3δ可以保證99.7%的樣本落入[0，μ+3δ]，如果服務運行穩(wěn)定并令μ+3δ小于2s，則能保證APDEX指標趨向于1.00[T]，使應用服務水平不斷提高。為使公式更具有通用性并可自動定義相關參數，以上模型內的2s和8s可使用以下公式代替，最終模型為：

其中，a為{μi+3δi}的50分位數，取b為{μi+3δi}的99分位數[4]。{μi+3δi}為該應用各服務響應時長的均值加上三倍方差的集合。

五、結束語

保險行業(yè)的應用有其獨特之處，結合保險行業(yè)的業(yè)務應用情況，采用ELK技術棧計算APDEX指標，可實時模擬用戶體驗，快速確定系統(tǒng)故障，提出優(yōu)化建議。對用戶體驗的持續(xù)優(yōu)化起到積極作用。隨著業(yè)務模式的改變和系統(tǒng)架構的調整，APDEX指標和T值的計算方式也不會一成不變，而將持續(xù)更新和優(yōu)化。

參 考 文 獻

[1] 林珊珊. 保險應用系統(tǒng)的若干模式[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] 盛驟. 概率論與數理統(tǒng)計（第四版）[M]. [2010.10.01]. 高等教育出版社