淺述APM採樣與端到端

極牛技術實踐分享活動

極牛技術實踐分享系列活動是極牛聯合頂級VC、技術專家，爲企業、技術人提供的一種系統的線上技術分享活動。

每期不一樣的技術主題，和行業專家深度探討，專一解決技術實踐難點，推進技術創新，每兩週的週三20點正式開課。歡迎各個機構、企業、行業專家、技術人報名參加。

主題大綱

淺述APM採樣與端到端

1.何爲APM

2.何爲端到端

3.何爲Apdex

1. 採樣的作法與弊端

嘉賓介紹

高馳濤(Neeke)，PHP官方PECL開發組成員，SeasLog做者，雲智慧高級架構師。9年研發管理經驗，早期從事大規模企業信息化研發架構，09年涉足互聯網數字營銷領域並深刻研究架構與性能優化。2014年加入雲智慧，致力於APM產品的架構與研發。熱衷開源。崇尚敏捷，高效，GettingReal。

圖片描述

首先，「何爲APM」。

相信你們最近幾年應該已經逐步地在瞭解APM這個行業

APM ＝ ApplicationPerformance Management.

也即：應用性能管理

這裏有一段較正式地解釋說明： APM is the monitoring and management of performance andavailability of software applications.

http://en.wikipedia.org/wiki/...

APM關注的是應用和軟件的性能和可用性的監控以及管理。

隨着軟件和應用的發展，應用性能已經愈來愈受到傳統IT和互聯網企業的關注。

咱們來看一幅圖，聊一下爲何須要APM。這是一個普通網站或應用的架構模型。

從箭頭的指向，咱們能夠看到，用戶的請求穿透了不少個節點，最終從服務器取得資源，並呈現到用戶的面前。這其中任何一個節點出現了問題，均可能直接或間接致使用戶直觀感受的「應用不可響應」。

而要最終確認是哪個節點的問題，正是全部互聯網運維和研發人員，天天面臨的問題。

雲智慧通過抽象，得出了一個更簡單的模型

上面的模型歸納了一個應用的架構，以及APM所關注的幾個點：

1. 終端用戶體驗

2. 應用架構映射

3. 應用事務分析

4. 深度應用診斷

5. 數據分析報告

這5個層次，貫穿了上面的模型中的幾個抽象層：User，CDN，Server，Code，Data Store，Physical.

而APM所解決的，正是一個應用管理過程當中因爲性能而產生的問題和損失的監控，定位，解決和管理。

咱們引出今天的第二個問題，「何爲端到端」。咱們繼續把視點放在這個抽象圖上：

拋出一個問題： 若是用戶報告說，網站或應用，不能登陸，可能會是這個抽象圖中的哪層的緣由呢？

咱們對着幾個層來思考：

User： 會不會是用戶本身的網絡不穩定？

CDN： 會不會是CDN廠商節點故障？

Firewall：（這個不便多說。。）

Server： 會不會是WebServer負載太高？

Code:會不會是今天有一個上線，致使了登陸業務bug？

DataStore： 會不會是DB故障，或者有慢SQL？

Physical： 這個最直接，會不會是服務器磁盤或CPU壞掉了？

再拋出一個問題：有沒有一個辦法，能夠把這個報告問題的用戶，遇到的問題現象完整地呈現出來，即：用一條數據，把用戶的瀏覽器表現，CDN的表現，Server的表現，Code的執行，SQL的執行，物理層的監控數據，串接起來呈現呢？

這就是雲智慧所理解的"End to End"，即「端到端」。

第二個問題的答案是確定的，咱們正在就此努力，前幾天咱們剛剛開過一個全棧性能監控的發佈會。

雲智慧全棧應用性能管理解決方案是一套面向企業實際業務的端到端總體解決方案，其中IT數據的端到端採集和展示是雲智慧領先於國內其餘APM產品的重要特性之一，那麼咱們是如何進行數據採樣的，又是如何在「端到端」應用性能管理中知足用戶對業務數據性能衡量呢？

端到端有不少種理解，咱們的理解是：從終端用戶出發，將從Request到Response整個鏈路中涉及到的全部數據，有效地串接起來，這樣的數據纔是真正的端到端，而不是將數據按照時間序列進行簡單地羅列展示。

何爲Apdex

首先，須要確認一點，Apdex，是一個採樣算法的表現，也是一個被其餘APM廠商奉爲衡量應用性能核心指標的量化標準。採樣這個事提及來是最有意思的，有數學基礎或作過計算機研發的都會很是熟悉。基本上，全部有關數據統計或分析的場景，都離不開採樣。

採樣最直接的目的有兩個：減小計算量和下降描述難度。

採樣方法有很是多種，最簡單的，不管哪種語言，確定有一個random函數，對其施以隨機種子，而後綜合時間 / CPU即時頻率 / 內存地址等等信息，那麼出來的便是一個採樣值。像一些profile工具，開始執行的開關就是用這種方式，好比facebook開源的xhprof就很是典型。

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

在APM廠商中，廣泛採用這樣一種採樣算法來計算Apdex（Application Performance Index）.

之後提到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 ＝ ( 1 x 滿意 ＋0.5 x 容忍 ＋ 0 x 失望 ) / 樣本數

Apdex的計算首先定義一個標準量T，進而將待計算的樣本以T爲標準量劃爲三個區間。分別是： 小於等於 1T， 爲 Satisfactory （滿意） 大於1T，小於4T，爲 Tolerating （ 容忍 ） 大於等於4T，爲 Frustrated （ 失望 ）

有沒有注意到一點，失望樣本被忽略了。而滿意樣本，即鍾曲線最左側的極限值，也未被絕對平均。從計算公式中咱們能夠看到，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請求的前提下，關注超出響應閾值的請求。

步驟1、所有或部分請求經過hash算法，取得當前URI的hashkey；

步驟2、判斷請求是否爲首次訪問，如果否，則執行；

步驟3、若否是，則執行步驟四；

步驟3、開始追蹤本次請求，採集本次請求的哈希值，並將這次採集的哈希值記錄在散列圖中；步驟4、判斷是否容許追蹤，若否，則執行步驟五，如果，則執行步驟六；

步驟5、不追蹤，並於本次請求結束後，判斷是否將本次請求採集的哈希值記錄在Trace隊列中；

步驟6、判斷是否已經實施過追蹤，如果，則不追蹤，若否，則執行步驟七；

步驟7、啓動追蹤，並將被追蹤的次數記錄於Trace隊列中。

這樣作的優點是什麼呢？ 首先，咱們沒有漏掉任何一個請求，不管快或慢，在出現問題的一剎那，立刻開始關注這組請求，當它再次發生，則馬上進行全棧的追蹤。其次，自然地將數據請求進行分組，不依據時間分組，而是依據請求事務進行分組； 最後，在不影響全棧追蹤的前提下，很好地解決了性能問題。

這個算法默認是關閉的，在用戶須要的時候，作細微的參數配置，就能夠打開這個算法。也就是說，默認咱們連這個算法都沒有開啓。

沒有開啓時，其實會是全數據採樣，也即樣本率爲100% 爲何不採樣呢？ 由於咱們信奉的金典是，基於業務的端到端。 只要想作到端到端的業務追蹤，任何形式的採樣，均可能直接致使某一個關鍵請求的缺失。或者換句話說，咱們也在採樣，只不過樣本覆蓋率是100%。 這個算法你們能夠參考一下，或許會對相相似的場景，有一些借鑑意義。

這其實直接給咱們帶來了兩個極大的挑戰：

1. 如何保持性能，包括數據採集性能，和數據處理性能 咱們確實爲性能付諸了極大的努力，好比數據格式，數據結構，傳輸協議，數據壓縮，等等，自豪地告訴你們，咱們基本能夠保證對用戶低於5%的性能損耗。若是打開了上面所述的算法開關，則能夠將性能損耗有效下降到1%如下。

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

舉個例子：如何對海量請求的事務數據進行響應時間的分析。請求的事務數據：一個應用中的事務基本是不可枚舉的，由於有各類參數的存在；那麼在各類參數存在的前提上，怎麼對響應時間進行分析？ 這方面各廠商的作法是對這段時間內請求時間最慢的事務進行排序，列出TOP10，這是至關不負責任的作法。

爲何不負責任，客戶的原話是這樣的：我知道這就是個人TOP10，而後呢？每天說這個TOP10，週週說，月月說，這並不能反映個人應用健康狀態。咱們須要關注的是，某段時間內，請求次數又多，響應時間又相對較慢的這些事務。

因而咱們提出了三個維度的交叉：單位時間，請求次數，響應時間。首先構思這樣一幅矩陣圖，X軸是時間，左Y軸是請求次數，右Y軸是平均響應時間。 這些事務以向量散落在這個象限內，那麼咱們能夠得出，距離XY的左原點，距離最遠的，便是咱們所關注的。演化以後，咱們獲得了這個柱狀的散點圖。

由每次請求向下深鑽，則能夠獲得每一個請求的「端到端」數據呈現：

Q&A

Q1：如何經過APM定位到線上服務瓶頸在哪裏？

A1：APM所要求的幾個點中，有比較重要的一個點，便是應用架構映射。幾乎全部的APM產品，都會知足這樣的需求：自動映射服務中的架構結構和性能表現。 這裏展現一下雲智慧的應用架構映射：

注意右上角：

咱們能夠觀察到這個應用，有27%的請求很是慢。 這些請求以及相對應的sql都在對應的視圖中有表現：咱們點選第一個表的操做統計。

Q2：若是服務器壓力增長，咱們能不能經過簡單的加機器來解決，須要加多少臺機器，這個場景下，怎麼使用APM？

A2：對負載的解決，最直接的方式確實是增長機器，分擔負載。此時，APM帶來的應用是，準確地評估現有集羣中機器的負載狀況和對應的請求。咱們能夠從APM產品中「主機」與「應用」交叉的維度來分析這個問題。以透視寶爲例：一眼能夠看到，目前集羣中，主機的負載能力和所承擔的應用服務狀況。此時，須要對哪一個應用添加機器，添加多少機器，能夠緩解多少負載壓力，均可以有數據進行佐證。

Q3：APM經過探針侵入式方式來收集診斷數據，對企業而言敏感和隱私數據擔憂泄露，這個問題APM廠商怎麼來處理？

A3：衆所周知，APM的技術門檻相對較高，探針的研發目前仍然是一個入門瓶頸，而這同時，也意味着，企業所選擇的服務廠商相對比較少，不會像普通建站業務那樣處處都是，APM廠商的服務相對質量也是更高的；

基本上全部廠商在進行數據採集和數據傳輸的過程當中都會採用壓縮，或二進制傳輸的方式，來下降數據泄露風險；

雲智慧在帶來高質量服務和高私密傳輸的處理作法上，同時提供私有化部署，即將saas服務轉化爲私有云，來解決企業更高的數據安全需求。同時咱們擁有專業的實施團隊，能夠充分地保證更高質量的私有云服務。

Q4：請問性能達5%是靠算法實現嗎？監控寶是怎樣採集不一樣語法的性能?

A4：性能5%的影響，不是靠算法實現的。而是靠更快的數據序列化方法和更精準的類hook完成。若是採用算法，能夠承諾在1%如下的性能影響；

不一樣語法，應該是指不一樣語言吧； 咱們經過不一樣語言的容器hook或字節碼修改，來進行準確的數據攔截和採集， 目前提供的語言Agent包含PHP,Java,DotNet,Python，基本能夠覆蓋95%以上的IT企業和互聯網企業需求。

Q5：對於內部代碼監控是採用aop方式進行切面採集嗎，是用開源組件仍是所有自研？在這一過程當中有哪些坑，已經trouble_shooting了?

A5：首先確認一點，咱們在Java語言層面，並不是使用aop進行切面採集；

而是經過在語言啓動時，動態修改字節碼來完成，其實交給jvm執行的，已是被咱們Agent Hook以後的代碼了；

Hook內容包括類方法的執行開始和執行結束； 攔截到的是類和方法的執行順序和執行參數，執行時間；Hook內容包括類方法的執行開始和執行結束； 攔截到的是類和方法的執行順序和執行參數，執行時間；

這一過程當中有很多坑，咱們目前發現的坑已經填得差很少了，同時在客戶使用過程當中也可能會有坑存在，但因爲是自研，因此處理速度很是及時有效；

舉一個坑的例子，因爲修改字節碼交給jvm，在大量代碼的項目中，啓動時間會比較長，咱們採起的作法是，默認關注一些類和資源driver，以減小這部分的啓動時間消耗，剩餘的類「白名單」和「黑名單」能夠由用戶進行配置便可。

＊此分享由PHP官方PECL高馳濤(Neeke)開發組成員在極牛線上技術分享羣裏所分享，有意加入的技術朋友，請在極牛公衆號(ji-niu)裏回覆「技術分享」。

下期預告

分享時間

2016年11月9日 晚8:00

分享形式

線上微信羣圖文直播

嘉賓介紹

方坤、9年服務器開發和雲計算領域解決方案經驗.曾任Intel亞太研發公司軟件開發工程師和UCloud雲計算高級解決方案架構師，熟悉互聯網領域多種應用場景，有豐富的初創企業IT解決方案項目設計經驗。目前在AWS中國負責推廣針對初創企業的最佳雲計算架構實踐。

主題大綱：

從零到千萬用戶的雲端(AWS)基礎架構最佳實踐

1. 雲計算服務（AWS）的介紹

2. 隨着從0到千萬用戶的業務增加，經過aws的不一樣服務輕鬆地實現高性能和高可用的基礎架構。