據云智慧統計，APM從客戶端采集的性能數據可能占到業務數據的50%，而企業要做到從Request到Response整個鏈路中涉及到的所有數據的準確采集，并進行有效串接，進而實現真正的端到端，絕非一件易事。
那么云智慧是如何進行APM數據采樣的，又是如何在“端到端”應用性能管理中滿足用戶對業務數據的高性能分析的呢？在2016年9月全球運維大會的APM專場上，云智慧首席架構師高馳濤先生為你揭曉APM背后的大數據奧秘。
高馳濤（Neeke Gao），云智慧首席架構師，PHP/PECL開發組成員，同時也是PECL/SeasLog,PECL/JsonNet,GoCrab等多項開源軟件作者。10年+研發管理經驗，早期從事大規模企業信息化架構研發，09年涉足互聯網數字營銷領域并深入研究架構與性能優化。2014 年加入云智慧，致力于 APM 產品的架構研發，崇尚敏捷，高效，GettingReal。
以下是高馳濤的精彩分享：
今天是APM專場，相信大家對APM都有一定了解，我就從APM的數據采樣與端到端的幾個層面進行分享，這也是云智慧近幾年在服務和解決客戶需求過程中的實踐結果。
APM和大數據

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

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

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

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

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

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

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

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

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

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