雲智慧全棧應用性能管理解決方案是一套面向企業實際業務的端到端整體解決方案，其中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算法起源於對一個傳統數據方法的質疑，這個傳統方法就是正態分佈，也叫高斯分佈。正態分佈的定義：
正態分佈應用非常廣泛，比如用來對比班級之間的成績，或用來對比某兩組數據的屬性差異時，會用它來作爲衡量標準。正態分佈非常的標準和簡單，但它有三個明顯的問題：
衡量時，使用的是平均值，因此，它假定了 「占主導地位的值是最重要的」。
計算時，進一步取向平均的值是不重要的，因爲，它假定了那些值 「偏離了規範」。
計算時，它過分誇大了曲線兩端的極限值，因爲，它假定了 「分佈在兩端的數據會被平均，而影響其他值」。
這三個問題是正態分佈在數據統計時存在的明顯缺陷。而Apdex的算法針對以上三個問題，作了一個演進。Apdex的計算首先定義一個標準量T，進而將待計算的樣本以T爲標準量劃爲三個區間。分別是：
小於等於 1T， 爲 Satisfactory （滿意）
大於1T，小於4T，爲 Tolerating （ 容忍 ）
大於等於4T，爲 Frustrated （ 失望 ）
此時，Apdex ＝ ( 1 x 滿意 ＋ 0.5 x 容忍 ＋ 0 x 失望 ) / 樣本數
有沒有注意到一點，失望樣本被忽略了。而滿意樣本，即鍾曲線最左側的極限值，也未被絕對平均。從計算公式中我們可以看到，Apdex假定你的樣本就是屬於標準正態分佈的，並且減輕曲線兩端對衡量值的影響。
首先聲明標量T ＝ 2s
假定樣本爲：
小於2s的請求次數爲10次，滿意；
大於2s，小於8s的請求次數爲20次，容忍；
大於等於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%。這其實直接給我們帶來了兩個極大的挑戰：
如何保持性能，包括數據採集性能，和數據處理性能
我們確實爲性能付諸了極大的努力，比如數據格式，數據結構，傳輸協議，數據壓縮，等等，自豪地告訴大家，我們基本可以保證對用戶低於5%的性能損耗。如果打開了上面所述的算法開關，則可以將性能損耗有效降低到1%以下。取得了大量的數據，如何對這海量數據進行分析
請求的事務數據：一個應用中的事務基本是不可枚舉的，因爲有各種參數的存在；那麼在各種參數存在的前提上，怎麼對響應時間進行分析？這方面各廠商的做法是對這段時間內請求時間最慢的事務進行排序，列出TOP10，這是相當不負責任的做法。
爲什麼不負責任，客戶的原話是這樣的：我知道這就是我的TOP10，然後呢？天天說這個TOP10，週週說，月月說，這並不能反映我的應用健康狀態。我們需要關注的是，某段時間內，請求次數又多，響應時間又相對較慢的這些事務。
於是我們提出了三個維度的交叉：單位時間，請求次數，響應時間。首先構思這樣一幅矩陣圖，X軸是時間，左Y軸是請求次數，右Y軸是平均響應時間。這些事務以向量散落在這個象限內，那麼我們可以得出，距離XY的左原點，距離最遠的，即是我們所關注的。
演化之後，我們得到了這個柱狀的散點圖。
我們的產品和技術還在不停地演進中，相信會越來越趨合最根本最真實的需求。