據(jù)云智慧統(tǒng)計(jì)，APM從客戶端采集的性能數(shù)據(jù)可能占到業(yè)務(wù)數(shù)據(jù)的50%，而企業(yè)要做到從Request到Response整個(gè)鏈路中涉及到的所有數(shù)據(jù)的準(zhǔn)確采集，并進(jìn)行有效串接，進(jìn)而實(shí)現(xiàn)真正的端到端，絕非一件易事。
那么云智慧是如何進(jìn)行APM數(shù)據(jù)采樣的，又是如何在“端到端”應(yīng)用性能管理中滿足用戶對業(yè)務(wù)數(shù)據(jù)的高性能分析的呢？在2016年9月全球運(yùn)維大會(huì)的APM專場上，云智慧首席架構(gòu)師高馳濤先生為你揭曉APM背后的大數(shù)據(jù)奧秘。
高馳濤（Neeke Gao），云智慧首席架構(gòu)師，PHP/PECL開發(fā)組成員，同時(shí)也是PECL/SeasLog,PECL/JsonNet,GoCrab等多項(xiàng)開源軟件作者。10年+研發(fā)管理經(jīng)驗(yàn)，早期從事大規(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ù)采樣與端到端的幾個(gè)層面進(jìn)行分享，這也是云智慧近幾年在服務(wù)和解決客戶需求過程中的實(shí)踐結(jié)果。
APM和大數(shù)據(jù)

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

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

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

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

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

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

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

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

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

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