昌盛 李井波

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

【關(guān)鍵詞】 APDEX 應(yīng)用性能指數(shù) ELK 保險應(yīng)用

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

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

一、概述

1.1 APDEX介紹

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

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

1.2 APDEX的優(yōu)勢

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

二、實現(xiàn)原理

2.1定義報告組

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

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

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

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

2.2定義性能區(qū)間

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

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

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

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

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

滿意：[0-T）

可容忍：[T-4T）

失望：[4T-∞）

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

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

3.3統(tǒng)計樣本數(shù)

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

3.4計算APDEX值

3.5報告結(jié)果

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

各數(shù)據(jù)后的下標“T”作為結(jié)果的一部分展現(xiàn)，例如當T=2時，APDEX=0.79時，最終展現(xiàn)的數(shù)據(jù)為0.792。

各滿意度區(qū)間關(guān)聯(lián)如下：

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

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

3.1基于ELK技術(shù)棧的日志采集模型

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

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

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

4.2前端日志改造

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

WebLogic Server默認的Access Log不包含交易時間，無法用于性能分析，因此需要進行相應(yīng)的日志改造。改造根據(jù)W3C規(guī)范，我們將WebLogic Server的Access Log改造成如下格式：

date time c-ip cs-method cs-uri time-taken sc-status bytes定義如下：

date：事務(wù)完成的日期

time：事務(wù)完成的時間

c-ip：客戶端IP地址

cs-method：請求的方法，如GET或POST

cs-uri：請求的完整URI

time-taken：完成交易需要的時間，單位為秒

sc-status：響應(yīng)狀態(tài)碼，如404

bytes：事務(wù)傳輸?shù)淖止?jié)數(shù)，單位為字節(jié)

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

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

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

根據(jù)對現(xiàn)有保險應(yīng)用的梳理，歸納出以下三點假設(shè)：

各應(yīng)用由若干服務(wù)組成，一般每個應(yīng)用包含不少于10個服務(wù)；

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

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

根據(jù)以上假設(shè)，我們確定T值有如下特點：

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

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

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

因此，T值可定義為：

其中，μ，δ分別為該應(yīng)用所有服務(wù)在過去的45天內(nèi)的響應(yīng)時長的均值和標準差。

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

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

五、結(jié)束語

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

參 考 文 獻

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