高馳濤 云智慧首席架構(gòu)師

創(chuàng)新互聯(lián)建站服務(wù)項目包括賀蘭網(wǎng)站建設(shè)、賀蘭網(wǎng)站制作、賀蘭網(wǎng)頁制作以及賀蘭網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，賀蘭網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到賀蘭省份的部分城市，未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

據(jù)云智慧統(tǒng)計，APM從客戶端采集的性能數(shù)據(jù)可能占到業(yè)務(wù)數(shù)據(jù)的50%，而企業(yè)要做到從Request到Response整個鏈路中涉及到的所有數(shù)據(jù)的準(zhǔn)確采集，并進行有效串接，進而實現(xiàn)真正的端到端，絕非一件易事。

那么云智慧是如何進行APM數(shù)據(jù)采樣的，又是如何在“端到端”應(yīng)用性能管理中滿足用戶對業(yè)務(wù)數(shù)據(jù)的高性能分析的呢？在2016年9月全球運維大會的APM專場上，云智慧首席架構(gòu)師高馳濤先生為你揭曉APM背后的大數(shù)據(jù)奧秘。

高馳濤（Neeke Gao），云智慧首席架構(gòu)師，PHP/PECL開發(fā)組成員，同時也是PECL/SeasLog,PECL/JsonNet,GoCrab等多項開源軟件作者。10年+研發(fā)管理經(jīng)驗，早期從事大規(guī)模企業(yè)信息化架構(gòu)研發(fā)，09年涉足互聯(lián)網(wǎng)數(shù)字營銷領(lǐng)域并深入研究架構(gòu)與性能優(yōu)化。2014 年加入云智慧，致力于 APM 產(chǎn)品的架構(gòu)研發(fā)，崇尚敏捷，高效，GettingReal。

以下是高馳濤的精彩分享：

今天是APM專場，相信大家對APM都有一定了解，我就從APM的數(shù)據(jù)采樣與端到端的幾個層面進行分享，這也是云智慧近幾年在服務(wù)和解決客戶需求過程中的實踐結(jié)果。

APM和大數(shù)據(jù)

在APM使用過程中有一個非常明顯的特征，就是可采集的數(shù)據(jù)量非常大，大到不可想象，看看上面這個機房，誰能準(zhǔn)確說出里面每天有多少數(shù)據(jù)流轉(zhuǎn)，而這只是幾臺簡單的機柜。我們對客戶的數(shù)據(jù)做過統(tǒng)計，在互聯(lián)網(wǎng)上，APM從客戶端采集回來的數(shù)據(jù)能夠占到企業(yè)業(yè)務(wù)數(shù)據(jù)的50%以上，這就意味著如果采集數(shù)據(jù)非常詳細(xì)，很可能會比原始業(yè)務(wù)數(shù)據(jù)量還要龐大。假設(shè)業(yè)務(wù)數(shù)據(jù)帶寬是2T，為了支撐APM又要上2T的帶寬，支撐業(yè)務(wù)的服務(wù)器可能要三百臺，現(xiàn)在要最少再額外增加150臺支撐APM，這在數(shù)據(jù)處理方面是個很大的挑戰(zhàn)，對于大多數(shù)企業(yè)來說，APM并不是企業(yè)的核心業(yè)務(wù)，但是用了非常多的計算與存儲資源。這是數(shù)據(jù)未作采樣時的現(xiàn)狀。

什么是APM（Application Performance Management），從字面上看就是“應(yīng)用+性能+管理”，前面兩位嘉賓聊的都是APM的范疇，他們聊的核心就是應(yīng)用性能，注意不是業(yè)務(wù)而是性能。APM后面還有一個詞是管理，就是從業(yè)務(wù)的角度理解這個性能數(shù)據(jù)，比如說一個崩潰或者說一個卡頓會影響多少用戶，影響的用戶會給企業(yè)造成多少損失，這就是APM對業(yè)務(wù)價值方面的體現(xiàn)，也是我們正在努力和實踐的方向。

我們?yōu)槭裁匆肁PM，今天有騰訊的嘉賓，舉個在手機上玩CF游戲的例子，一個玩家在玩CF，最近常常因為應(yīng)用運行卡頓被人打死，即便買了好槍、好裝備還是打不過別人，用戶必然會投訴，投訴之后客服會根據(jù)系統(tǒng)的知識庫問一大堆有的沒的問題，然后承諾玩家馬上安排運維檢查系統(tǒng)，最后往往不了了之。在企業(yè)業(yè)務(wù)人員在服務(wù)用戶的過程中往往缺少一個工具，或者說一個平臺來及時、準(zhǔn)確的發(fā)現(xiàn)用戶問題，甚至定位到具體用戶，具體SQL和具體關(guān)鍵代碼。

APM有兩大好處，一個是可以提升工作效率，減少和用戶無效溝通的時間；另一個就是及時發(fā)現(xiàn)和準(zhǔn)確定位問題，因為運行在互聯(lián)網(wǎng)上的業(yè)務(wù)系統(tǒng)，往往是用戶最先感知到系統(tǒng)故障，如果能在接到用戶反饋的第一時間及時發(fā)現(xiàn)和解決問題，就會大大降低故障帶來的業(yè)務(wù)損失。舉個簡單的例子，云智慧有個客戶的生產(chǎn)系統(tǒng)故障導(dǎo)致停服兩個小時，造成了好幾千萬的損失，后臺運維的解決辦法非常簡單，把服務(wù)切了一下，重新啟了一套集群，把業(yè)務(wù)切過去，現(xiàn)場保留下來了，之后用了一個星期的時間發(fā)現(xiàn)其實是內(nèi)存泄露。他們用一個星期的時間找到了問題，后來在云智慧透視寶的幫助下，直接在測試系統(tǒng)上重現(xiàn)了這個問題，并且在10分鐘內(nèi)準(zhǔn)確地定位到了內(nèi)存泄露的位置，使用APM可以有效地縮短問題的發(fā)現(xiàn)時間，并有效解決，避免再次發(fā)生類似問題。

為什么說APM是大數(shù)據(jù)呢？我們知道大數(shù)據(jù)有著非常明確的4V特征: 

一個是數(shù)據(jù)量大（Volume），我們的一個典型用戶，每天在APM系統(tǒng)中產(chǎn)生的數(shù)據(jù)存儲量超過了500G；

一個是種類繁多(Variety)，例如目前我們已知的移動端APM指標(biāo)超過三百多個，維度更多；

一個是高速（Velocity），數(shù)據(jù)產(chǎn)生的速度和消費的速度都是非?？植赖模?/p>

一個是數(shù)據(jù)價值（Value），單條數(shù)據(jù)價低，需要綜合大量數(shù)據(jù)進行多緯度綜合分析，以得出數(shù)據(jù)現(xiàn)狀和趨勢；

這是大數(shù)據(jù)的典型特征， APM數(shù)據(jù)恰好符合。

Apdex的得失

面對這么大的數(shù)據(jù)量應(yīng)該怎么做，最直接有效的方式就是采樣。為什么要做采樣，一個是可以有效降低數(shù)據(jù)量，從數(shù)據(jù)價值角度來說我們不希望一條數(shù)據(jù)漏掉，但當(dāng)大量數(shù)據(jù)進來以后，為了描述一天的數(shù)據(jù)量需要花費幾天的時間，這就意味著永遠(yuǎn)無法準(zhǔn)確描述。

怎么處理呢？大家看這個Jmeter的請求散點圖，在上面標(biāo)注密密麻麻的點，一個請求一個點位，根據(jù)時間維度和響應(yīng)時間不停地在畫布上面點。這時候很難點到每個準(zhǔn)確的點，只是比較客觀的描述一個事情，就像是一篇流水賬，但是不能描述整個應(yīng)用，也不能描述這個應(yīng)用是什么樣子。

利用這個散點圖可以做出這樣的一個二維的柱狀圖，同一個柱狀圖上又有面積又有高度又有時間，這樣好幾個維度交叉起來做一個二維圖，右側(cè)是從大量不同維度的數(shù)據(jù)里把幾個指標(biāo)通過APDEX算法融合成一個Apdex指標(biāo)。

APDEX就是應(yīng)用性能指標(biāo)，是APM領(lǐng)域共同遵循的一個規(guī)范標(biāo)準(zhǔn)，這個算法不僅限于應(yīng)用性能領(lǐng)域，在很多我們想要用同一個指標(biāo)描述大量數(shù)據(jù)的時候都可以用。我們先看看為什么要用APDEX，左邊這張圖是高斯分布，也就是正態(tài)分布圖，可以把一個指標(biāo)的散點圖畫到這個地方，形成一張高斯分布圖，它的波動曲線上波峰越高說明性能越差，越平緩說明性能越好。但這種描述方式有個明顯的缺點，很容易忽略兩極，這個圖兩極是響應(yīng)速度最快或者最慢的情況，而高斯分布更關(guān)注中庸?fàn)顟B(tài)，假設(shè)非中庸的數(shù)據(jù)都是異常數(shù)據(jù)，這就意味著描述的時候其實把看起來非常棒和非常差的狀態(tài)丟棄了，只留下中庸數(shù)據(jù)。

APDEX是對高斯分布的一個改良，這個柱是一個標(biāo)尺，這個標(biāo)尺最上面1.00T，T是APDEX的一個單位，APDEX是從0到1描述一項指標(biāo)，比如計算應(yīng)用在某一天的平均響應(yīng)時間，假設(shè)一共有四十個請求，平均響應(yīng)時間是兩秒，低于兩秒的時候設(shè)為一，從零到兩秒是十個請求計成一，從兩秒到八秒有二十個計成0.5，另外十個大于八秒的計成零，得到APDEX的計算結(jié)果是（1×10+0.5×20+0×10）÷40=0.75。用這個方法可以描述應(yīng)用在一天內(nèi)的響應(yīng)時間指標(biāo)是0.75，把0.75放在這個柱子上看還可接受，如果低于0.5是完全不可接受，可能是有故障。這就是APDEX算法，可以用一個值去描述應(yīng)用在一段時間內(nèi)大量采樣數(shù)據(jù)的整體狀況。

APDEX有什么問題呢？以血壓為例子，比如說高壓120是標(biāo)桿，有40個人進行測量，這40個人像剛才說的，優(yōu)秀的10個，中庸的20個，血壓偏高已經(jīng)不行的人占了10個，描述40個人的健康狀況得出一個還不錯的數(shù)據(jù)0.75。這個時候就有一個非常可怕的問題，用0.75去描述這個人群是沒問題的，但是忽略了最后大于四倍標(biāo)量時候的那部分?jǐn)?shù)據(jù)，也就是說那10個快要死的人根本沒管他，這是APDEX最大的問題。APDEX的另一個問題是原始數(shù)據(jù)和端到端的缺失，因為APDEX是通過數(shù)據(jù)流動過程中直接計算出指標(biāo)來節(jié)省大量存儲的，不但原始數(shù)據(jù)沒了，端到端數(shù)據(jù)也被拋棄了。

再舉一個更直接的例子，如果應(yīng)用系統(tǒng)的數(shù)據(jù)庫連接池出現(xiàn)了問題，此時整個應(yīng)用接受到的請求在判斷連接池出現(xiàn)問題后，可能會快速地拋出一個異常并響應(yīng)前端一個靜態(tài)頁，此時整個應(yīng)用響應(yīng)非?？焖?，APDEX值也會非常的理想，而整個應(yīng)用的性能其實是非常非常差的，因為正常的業(yè)務(wù)全部被中斷了。

真正的端到端和APM的采樣

真正的端到端是能夠串聯(lián)各個請求從客戶端到后面的網(wǎng)絡(luò)、DB、物理層、外部服務(wù)、文件操作的整個鏈路的數(shù)據(jù)，數(shù)據(jù)是不能存在數(shù)據(jù)孤島的，如果可以通過一個ID號或者是時間維度把數(shù)據(jù)進行串接，這才是真正的端到端。

這張圖的中間一層就是端到端鏈路，端到端的實現(xiàn)就是在每個點上的這么多服務(wù)、組件上采集數(shù)據(jù)，，同時由一個惟一標(biāo)識在各個服務(wù)組件上采集的數(shù)據(jù)中作出傳遞； 在分析客戶端用戶行為的同時，還可以通過一個客戶端的API調(diào)用，直接追蹤到API對應(yīng)后端執(zhí)行的SQL和執(zhí)行的代碼棧，以及同時刻服務(wù)器的CPU/內(nèi)存/網(wǎng)絡(luò)/IO等系統(tǒng)狀態(tài)。其中最大的難題是采樣，在使用了APDEX的同時還要實現(xiàn)端到端，這其實就是一個矛盾，既要準(zhǔn)確地描述應(yīng)用的情況，又想降低描述的難度，而且一條數(shù)據(jù)都不丟，這是一個非常大的挑戰(zhàn)。

這個時候有很多做法，這張圖是為客戶測試解決方案時的一個真實機器負(fù)載數(shù)據(jù)圖，TPS降低4%，CPU資源使用率在5%以下。這是怎么做到的呢？我們在數(shù)據(jù)傳輸以及數(shù)據(jù)采集的地方做了大量的工作。比如說系統(tǒng)或接口有問題，問題可能在哪里？根據(jù)研發(fā)和運維經(jīng)驗很有可能是在進行操作或者有了網(wǎng)絡(luò)請求，還有一種可能情況是內(nèi)存和CPU的資源情況，知道這些條件之后，就可以有針對的采集數(shù)據(jù)，而不是一股腦全部采集。還有就是在不丟數(shù)據(jù)的前提下，要把一款日PV達到百萬級的應(yīng)用覆蓋全，也是一個很大的挑戰(zhàn)。

這是云智慧的端到端數(shù)據(jù)采集原理圖，我們的目標(biāo)是全量采集，同時要關(guān)注各個響應(yīng)閾值，時間的響應(yīng)閾值、CPU和內(nèi)存響應(yīng)閾值，還有錯誤和異常。為什么說是錯誤和異常？因為通常意義上的APDEX是對響應(yīng)時間這個指標(biāo)進行計算，做規(guī)定的描述。

比如說通過一個接口或者通過一個頁面訪問一條新聞，發(fā)一個請求，獲取一篇文章，如果響應(yīng)時間一百毫秒之內(nèi)非常棒，但很有可能響應(yīng)時間一百毫秒的時候要連接一次，連接一次之后要再寫一次緩存或者寫一個點擊量什么的操作，這個時候返回這是一個正常的業(yè)務(wù)，但是很有可能沒有連上，產(chǎn)生了錯誤或者異常，而響應(yīng)時間是90毫秒，我們能說這個90毫秒的響應(yīng)請求比一百毫秒更好嗎？所以單純用響應(yīng)時間這個指標(biāo)去衡量性能是有問題的，我們應(yīng)該在關(guān)注響應(yīng)時間指標(biāo)的同時關(guān)注異常指標(biāo)，而異常指標(biāo)比正常指標(biāo)更重要，在進行APDEX衡量的時候一定要進行異常指標(biāo)的關(guān)注。

最后舉個APM應(yīng)用實例，這是監(jiān)控寶在使用前和使用后的對比，右上角是響應(yīng)時間占比，下面有訪問時間等等，大家可以看到右上角×××部分就是緩慢響應(yīng)，其實會發(fā)現(xiàn)應(yīng)用有很多問題，緩慢數(shù)量大于了90%左右，這是錯誤和異常的指標(biāo)，優(yōu)化數(shù)據(jù)滿眼都是綠色，查詢的響應(yīng)時間明顯降下來了，這就是響應(yīng)時間和錯誤相交叉的一個指標(biāo)表現(xiàn)。通過事務(wù)快照還可以查看每個具體請求的代碼運行棧/SQL/API請求/請求參數(shù)等指標(biāo)，如果有錯誤或異常還可以快速地查看錯誤或異常的詳情。

謝謝大家！

Q：我想問一下APDEX是APM行業(yè)內(nèi)的標(biāo)準(zhǔn)，還是云智慧多年來的經(jīng)驗總結(jié)？

高馳濤：APDEX定義是來自于APM這個詞，這個詞是從APM出現(xiàn)以后才有的，而APDEX也是許多專業(yè)分析師提出來的標(biāo)準(zhǔn)。剛才說的四倍標(biāo)量給定義0.5，大于四倍給零，這個其實沒有約定，但是大家一直是這么做的，算一個未成文的約定。

剛才說了關(guān)注幾個采樣，關(guān)注響應(yīng)時間、響應(yīng)閾值，響應(yīng)閾值包括訪問時間，這是一個關(guān)注指標(biāo)，在采集的時候首先可以確定連接，不管連接有多快、多慢、有沒有出錯，都必須要采集，因為這是未知的非常關(guān)鍵的操作，關(guān)鍵操作一定要采集。還有對于正常操作，比如說沒有發(fā)生錯誤也沒有發(fā)生異常，CPU和內(nèi)存正常，這個時候如果響應(yīng)時間的閾值低于一毫秒的方法我們會拋棄掉。

云智慧所有的設(shè)計都要求不讓用戶改一行代碼，無工程侵入；如果要進行編碼才能獲取數(shù)據(jù)的話，是完全沒有必要使用第三方平臺的，開發(fā)者自己就可以輕松地實現(xiàn)。云智慧從無到有是必須要冷部署的，從有到暫停或者說從有到卸載是可以熱部署的。

云智慧是業(yè)務(wù)運維解決方案服務(wù)商，旗下產(chǎn)品監(jiān)控寶（www.jiankongbao.com ）、透視寶（www.toushibao.com）、壓測寶（www.yacebao.com），已累計為電商、移動互聯(lián)網(wǎng)、廣告?zhèn)髅?、在線游戲、教育醫(yī)療、金融證券、政企等行業(yè)的幾十萬用戶提供了一站式的應(yīng)用性能監(jiān)控、管理及測試服務(wù)。