詳解APM數據採樣與端到端

據云智慧統計，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和內存正常，這個時候若是響應時間的閾值低於一毫秒的方法咱們會拋棄掉。雲智慧全部的設計都要求不讓用戶改一行代碼，無工程侵入；若是要進行編碼才能獲取數據的話，是徹底沒有必要使用第三方平臺的，開發者本身就能夠輕鬆地實現。雲智慧從無到有是必需要冷部署的，從有到暫停或者說從有到卸載是能夠熱部署的。