云智慧全棧應用性能管理解決方案是一套面向企業實際業務的端到端整體解決方案，其中IT數據的端到端采集和展現是云智慧領先于國內其他APM產品的重要特性之一，那么我們是如何進行數據采樣的，又是如何在“端到端”應用性能管理中滿足用戶對業務數據性能衡量呢?本文將為您一一道來。

　　首先理解一下我們對“端到端”的定義，“端到端”就是很多年前業內就在提的End2End，現在業內幾個APM廠商在云智慧提出端到端概念之后，也在這么吆喝。端到端有很多種理解，我們的理解是：從終端用戶出發，將從Request到Response整個鏈路中涉及到的所有數據，有效地串接起來，這樣的數據才是真正的端到端，而不是將數據按照時間序列進行簡單地羅列展現。

　　我們從上面的軟硬件模型中可以看到，一個用戶請求從前到后，經過了N多的節點才最終返回數據并展現在用戶面前，相信很多有經驗的開發和運維都曾經想，怎樣有效地將從用戶請求開始，將請求鏈路中的數據都采集到，并且有效地關聯起來。

　　下面就為您剖析一下“采樣”對于“端到端”應用性能管理的意義和實現。

　　為什么要采樣?

　　采樣這個事說起來是最有意思的，有數學基礎或做過計算機研發的都會非常熟悉。基本上，所有有關數據統計或分析的場景，都離開采樣。

　　采樣最直接的目的有兩個：減少計算量和降低描述難度。

　　采樣方法有非常多種，最簡單的，無論哪一種語言，肯定有一個random函數，對其施以隨機種子，然后綜合時間 / CPU即時頻率 / 內存地址等等信息，那么出來的即是一個采樣值。像一些profile工具，開始執行的開關就是用這種方式，比如facebook開源的xhprof就非常典型。

　　采樣還可以人為指定樣本，這也是一種常見的做法。比如，直接指定某一個特定標識，如時間，ip，或進程id，等有非常明確特指意義的屬性。如程序猿們在開發過程中，對一次具體請求的debug過程，非常典型。

 

　　在APM廠商中，普遍采用這樣一種采樣算法來計算Apdex。(注：云智慧并未采用這個采樣算法，后文會解釋原因。)先看看什么是Apdex，它是Application Performance Index 應用性能指數的縮寫，這個指數被其他的APM廠商奉為衡量應用性能的核心指標。它為用戶對應用性能滿意度進行量化，提供了一個測量標準。

　　以后提到Apdex，大家用這個圖來解釋：Apdex值是0 - 1的區間值，每個區間對應一個評價：1~0.94是優秀，0.94~0.85是良好，0.85~0.70是尚可，0.70~0.50是差評，低于0.50的Apdex值是用戶無法接受的。

　　這個值，怎么計算呢?

 

　　Apdex算法起源于對一個傳統數據方法的質疑，這個傳統方法就是正態分布，也叫高斯分布。正態分布的定義：

 

　　正態分布應用非常廣泛，比如用來對比班級之間的成績，或用來對比某兩組數據的屬性差異時，會用它來作為衡量標準。正態分布非常的標準和簡單，但它有三個明顯的問題：

　　l 衡量時，使用的是平均值，因此，它假定了 “占主導地位的值是最重要的”。

　　l 計算時，進一步取向平均的值是不重要的，因為，它假定了那些值 “偏離了規范”。

　　l 計算時，它過分夸大了曲線兩端的極限值，因為，它假定了 “分布在兩端的數據會被平均，而影響其他值”。

　　這三個問題是正態分布在數據統計時存在的明顯缺陷。而Apdex的算法針對以上三個問題，作了一個演進。Apdex的計算首先定義一個標準量T，進而將待計算的樣本以T為標準量劃為三個區間。分別是：

　　l 小于等于 1T， 為 Satisfactory (滿意)

　　l 大于1T，小于4T，為 Tolerating ( 容忍 )

　　l 大于等于4T，為 Frustrated ( 失望 )

　　此時，Apdex = ( 1 x 滿意 + 0.5 x 容忍 + 0 x 失望 ) / 樣本數

　　有沒有注意到一點，失望樣本被忽略了。而滿意樣本，即鐘曲線最左側的極限值，也未被絕對平均。從計算公式中我們可以看到，Apdex假定你的樣本就是屬于標準正態分布的，并且減輕曲線兩端對衡量值的影響。

　　首先聲明標量T = 2s

　　假定樣本為：

　　l 小于2s的請求次數為10次，滿意;

　　l 大于2s，小于8s的請求次數為20次，容忍;

　　l 大于等于8s的請求次數為10次，失望。

 

　　那么得到 Apdex = ( 1 x 10 + 0.5 x 20 + 0 x 10 ) / 40 = 0.5

　　拿這個標尺看一下0.5在哪里，已經接近“無法接受”了。所以，如果用Apdex來衡量剛才這組樣本，則認為，這個應用已經要掛了。

　　這個被廣大APM廠商奉為金典的標準，合理嗎?

　　我再舉一個例子以說明是否合理。假如上面計算的不是響應時間，而是一群人的血壓。如果樣本數據是一樣的，即：血壓滿意的為10, 血壓可容忍的為20, 血壓超高令人失望的為10。那么得出的這個0.5的結果，則意味著：這群人已經接近了“無法接受”狀態，快掛了，需要集體用藥。

　　是的，這個值只能說明一個概況，而并不能反映真實的現狀。因為它做到了簡單的整體衡量，而忽略了病患。不能說Apdex不合理，只是在具象的衡量上，標準并不能代表真實狀態。

　　接下來看看云智慧APM產品透視寶對數據采樣的方案，大家對比一下其優劣。

 

　　首先可以確定的是，云智慧的數據采樣算法并非統計方法。這個方法的設計思路是：充分覆蓋所有的URI請求的前提下，關注超出響應閾值的請求。　　步驟一、全部或部分請求通過hash算法，取得當前URI的hash key;

　　步驟二、判斷請求是否為***訪問，若是否，則執行步驟三，若否是，則執行步驟四;

　　步驟三、開始追蹤本次請求，采集本次請求的哈希值，并將此次采集的哈希值記錄在散列圖中;

　　步驟四、判斷是否允許追蹤，若否，則執行步驟五，若是，則執行步驟六;

　　步驟五、不追蹤，并于本次請求結束后，判斷是否將本次請求采集的哈希值記錄在Trace隊列中;

　　步驟六、判斷是否已經實施過追蹤，若是，則不追蹤，若否，則執行步驟七;

　　步驟七、啟動追蹤，并將被追蹤的次數記錄于Trace隊列中。

　　這樣做的優勢是什么呢?

　　首先，我們沒有漏掉任何一個請求，無論快或慢，在出現問題的一剎那，馬上開始關注這組請求，當它再次發生，則立刻進行全棧的追蹤。

　　其次，天然地將數據請求進行分組，不依據時間分組，而是依據請求事務進行分組;

　　***，在不影響全棧追蹤的前提下，很好地解決了性能問題。

　　這個算法默認是關閉的，在用戶需要的時候，做細微的參數配置，就可以打開這個算法。也就是說，默認我們連這個算法都沒有開啟。

　　為什么不采樣呢?

　　因為我們信奉的金典是，基于業務的端到端。只要想做到端到端的業務追蹤，任何形式的采樣，都可能直接導致某一個關鍵請求的缺失。或者換句話說，我們也在采樣，只不過樣本覆蓋率是100%。這其實直接給我們帶來了兩個極大的挑戰：

　　1. 如何保持性能，包括數據采集性能，和數據處理性能

　　我們確實為性能付諸了極大的努力，比如數據格式，數據結構，傳輸協議，數據壓縮，等等，自豪地告訴大家，我們基本可以保證對用戶低于5%的性能損耗。如果打開了上面所述的算法開關，則可以將性能損耗有效降低到1%以下。

　　2. 取得了大量的數據，如何對這海量數據進行分析

　　請求的事務數據：一個應用中的事務基本是不可枚舉的，因為有各種參數的存在;那么在各種參數存在的前提上，怎么對響應時間進行分析?這方面各廠商的做法是對這段時間內請求時間最慢的事務進行排序，列出***0，這是相當不負責任的做法。

　　為什么不負責任，客戶的原話是這樣的：我知道這就是我的***0，然后呢?天天說這個***0，周周說，月月說，這并不能反映我的應用健康狀態。我們需要關注的是，某段時間內，請求次數又多，響應時間又相對較慢的這些事務。

　　于是我們提出了三個維度的交叉：單位時間，請求次數，響應時間。首先構思這樣一幅矩陣圖，X軸是時間，左Y軸是請求次數，右Y軸是平均響應時間。這些事務以向量散落在這個象限內，那么我們可以得出，距離XY的左原點，距離最遠的，即是我們所關注的。

　　演化之后，我們得到了這個柱狀的散點圖。