據(jù)云智慧統(tǒng)計，APM從客戶端采集的性能數(shù)據(jù)可能占到業(yè)務數(shù)據(jù)的50%，而企業(yè)要做到從Request到Response整個鏈路中涉及到的所有數(shù)據(jù)的準確采集，并進行有效串接，進而實現(xiàn)真正的端到端，絕非一件易事。
那么云智慧是如何進行APM數(shù)據(jù)采樣的，又是如何在“端到端”應用性能管理中滿足用戶對業(yè)務數(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ù)字營銷領域并深入研究架構(gòu)與性能優(yōu)化。2014 年加入云智慧，致力于 APM 產(chǎn)品的架構(gòu)研發(fā)，崇尚敏捷，高效，GettingReal。
以下是高馳濤的精彩分享：
今天是APM專場，相信大家對APM都有一定了解，我就從APM的數(shù)據(jù)采樣與端到端的幾個層面進行分享，這也是云智慧近幾年在服務和解決客戶需求過程中的實踐結(jié)果。
APM和大數(shù)據(jù)

在APM使用過程中有一個非常明顯的特征，就是可采集的數(shù)據(jù)量非常大，大到不可想象，看看上面這個機房，誰能準確說出里面每天有多少數(shù)據(jù)流轉(zhuǎn)，而這只是幾臺簡單的機柜。我們對客戶的數(shù)據(jù)做過統(tǒng)計，在互聯(lián)網(wǎng)上，APM從客戶端采集回來的數(shù)據(jù)能夠占到企業(yè)業(yè)務數(shù)據(jù)的50%以上，這就意味著如果采集數(shù)據(jù)非常詳細，很可能會比原始業(yè)務數(shù)據(jù)量還要龐大。假設業(yè)務數(shù)據(jù)帶寬是2T，為了支撐APM又要上2T的帶寬，支撐業(yè)務的服務器可能要三百臺，現(xiàn)在要最少再額外增加150臺支撐APM，這在數(shù)據(jù)處理方面是個很大的挑戰(zhàn)，對于大多數(shù)企業(yè)來說，APM并不是企業(yè)的核心業(yè)務，但是用了非常多的計算與存儲資源。這是數(shù)據(jù)未作采樣時的現(xiàn)狀。
什么是APM（Application Performance Management），從字面上看就是“應用+性能+管理”，前面兩位嘉賓聊的都是APM的范疇，他們聊的核心就是應用性能，注意不是業(yè)務而是性能。APM后面還有一個詞是管理，就是從業(yè)務的角度理解這個性能數(shù)據(jù)，比如說一個崩潰或者說一個卡頓會影響多少用戶，影響的用戶會給企業(yè)造成多少損失，這就是APM對業(yè)務價值方面的體現(xiàn)，也是我們正在努力和實踐的方向。
我們?yōu)槭裁匆肁PM，今天有騰訊的嘉賓，舉個在手機上玩CF游戲的例子，一個玩家在玩CF，最近常常因為應用運行卡頓被人打死，即便買了好槍、好裝備還是打不過別人，用戶必然會投訴，投訴之后客服會根據(jù)系統(tǒng)的知識庫問一大堆有的沒的問題，然后承諾玩家馬上安排運維檢查系統(tǒng)，最后往往不了了之。在企業(yè)業(yè)務人員在服務用戶的過程中往往缺少一個工具，或者說一個平臺來及時、準確的發(fā)現(xiàn)用戶問題，甚至定位到具體用戶，具體SQL和具體關(guān)鍵代碼。
APM有兩大好處，一個是可以提升工作效率，減少和用戶無效溝通的時間；另一個就是及時發(fā)現(xiàn)和準確定位問題，因為運行在互聯(lián)網(wǎng)上的業(yè)務系統(tǒng)，往往是用戶最先感知到系統(tǒng)故障，如果能在接到用戶反饋的第一時間及時發(fā)現(xiàn)和解決問題，就會大大降低故障帶來的業(yè)務損失。舉個簡單的例子，云智慧有個客戶的生產(chǎn)系統(tǒng)故障導致停服兩個小時，造成了好幾千萬的損失，后臺運維的解決辦法非常簡單，把服務切了一下，重新啟了一套集群，把業(yè)務切過去，現(xiàn)場保留下來了，之后用了一個星期的時間發(fā)現(xiàn)其實是內(nèi)存泄露。他們用一個星期的時間找到了問題，后來在云智慧透視寶的幫助下，直接在測試系統(tǒng)上重現(xiàn)了這個問題，并且在10分鐘內(nèi)準確地定位到了內(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指標超過三百多個，維度更多；
一個是高速（Velocity），數(shù)據(jù)產(chǎn)生的速度和消費的速度都是非?？植赖模?br>一個是數(shù)據(jù)價值（Value），單條數(shù)據(jù)價低，需要綜合大量數(shù)據(jù)進行多緯度綜合分析，以得出數(shù)據(jù)現(xiàn)狀和趨勢；
這是大數(shù)據(jù)的典型特征， APM數(shù)據(jù)恰好符合。
Apdex的得失
面對這么大的數(shù)據(jù)量應該怎么做，最直接有效的方式就是采樣。為什么要做采樣，一個是可以有效降低數(shù)據(jù)量，從數(shù)據(jù)價值角度來說我們不希望一條數(shù)據(jù)漏掉，但當大量數(shù)據(jù)進來以后，為了描述一天的數(shù)據(jù)量需要花費幾天的時間，這就意味著永遠無法準確描述。

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

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

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

APDEX是對高斯分布的一個改良，這個柱是一個標尺，這個標尺最上面1.00T，T是APDEX的一個單位，APDEX是從0到1描述一項指標，比如計算應用在某一天的平均響應時間，假設一共有四十個請求，平均響應時間是兩秒，低于兩秒的時候設為一，從零到兩秒是十個請求計成一，從兩秒到八秒有二十個計成0.5，另外十個大于八秒的計成零，得到APDEX的計算結(jié)果是（1×10+0.5×20+0×10）÷40=0.75。用這個方法可以描述應用在一天內(nèi)的響應時間指標是0.75，把0.75放在這個柱子上看還可接受，如果低于0.5是完全不可接受，可能是有故障。這就是APDEX算法，可以用一個值去描述應用在一段時間內(nèi)大量采樣數(shù)據(jù)的整體狀況。
APDEX有什么問題呢？以血壓為例子，比如說高壓120是標桿，有40個人進行測量，這40個人像剛才說的，優(yōu)秀的10個，中庸的20個，血壓偏高已經(jīng)不行的人占了10個，描述40個人的健康狀況得出一個還不錯的數(shù)據(jù)0.75。這個時候就有一個非?？膳碌膯栴}，用0.75去描述這個人群是沒問題的，但是忽略了最后大于四倍標量時候的那部分數(shù)據(jù)，也就是說那10個快要死的人根本沒管他，這是APDEX最大的問題。APDEX的另一個問題是原始數(shù)據(jù)和端到端的缺失，因為APDEX是通過數(shù)據(jù)流動過程中直接計算出指標來節(jié)省大量存儲的，不但原始數(shù)據(jù)沒了，端到端數(shù)據(jù)也被拋棄了。
再舉一個更直接的例子，如果應用系統(tǒng)的數(shù)據(jù)庫連接池出現(xiàn)了問題，此時整個應用接受到的請求在判斷連接池出現(xiàn)問題后，可能會快速地拋出一個異常并響應前端一個靜態(tài)頁，此時整個應用響應非常快速，APDEX值也會非常的理想，而整個應用的性能其實是非常非常差的，因為正常的業(yè)務全部被中斷了。
真正的端到端和APM的采樣
真正的端到端是能夠串聯(lián)各個請求從客戶端到后面的網(wǎng)絡、DB、物理層、外部服務、文件操作的整個鏈路的數(shù)據(jù)，數(shù)據(jù)是不能存在數(shù)據(jù)孤島的，如果可以通過一個ID號或者是時間維度把數(shù)據(jù)進行串接，這才是真正的端到端。

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

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

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

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

最后舉個APM應用實例，這是監(jiān)控寶在使用前和使用后的對比，右上角是響應時間占比，下面有訪問時間等等，大家可以看到右上角黃色部分就是緩慢響應，其實會發(fā)現(xiàn)應用有很多問題，緩慢數(shù)量大于了90%左右，這是錯誤和異常的指標，優(yōu)化數(shù)據(jù)滿眼都是綠色，查詢的響應時間明顯降下來了，這就是響應時間和錯誤相交叉的一個指標表現(xiàn)。通過事務快照還可以查看每個具體請求的代碼運行棧/SQL/API請求/請求參數(shù)等指標，如果有錯誤或異常還可以快速地查看錯誤或異常的詳情。
謝謝大家！
Q：我想問一下APDEX是APM行業(yè)內(nèi)的標準，還是云智慧多年來的經(jīng)驗總結(jié)？
高馳濤：APDEX定義是來自于APM這個詞，這個詞是從APM出現(xiàn)以后才有的，而APDEX也是許多專業(yè)分析師提出來的標準。剛才說的四倍標量給定義0.5，大于四倍給零，這個其實沒有約定，但是大家一直是這么做的，算一個未成文的約定。
剛才說了關(guān)注幾個采樣，關(guān)注響應時間、響應閾值，響應閾值包括訪問時間，這是一個關(guān)注指標，在采集的時候首先可以確定連接，不管連接有多快、多慢、有沒有出錯，都必須要采集，因為這是未知的非常關(guān)鍵的操作，關(guān)鍵操作一定要采集。還有對于正常操作，比如說沒有發(fā)生錯誤也沒有發(fā)生異常，CPU和內(nèi)存正常，這個時候如果響應時間的閾值低于一毫秒的方法我們會拋棄掉。
云智慧所有的設計都要求不讓用戶改一行代碼，無工程侵入；如果要進行編碼才能獲取數(shù)據(jù)的話，是完全沒有必要使用第三方平臺的，開發(fā)者自己就可以輕松地實現(xiàn)。云智慧從無到有是必須要冷部署的，從有到暫?；蛘哒f從有到卸載是可以熱部署的。