摘要：主題大綱淺述采樣與端到端何為何為端到端何為采樣的做法與弊端嘉賓介紹高馳濤，官方開發組成員，作者，云智慧高級架構師。

極牛技術實踐分享活動

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

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

主題大綱

淺述APM采樣與端到端

1.何為APM

2.何為端到端

3.何為Apdex

采樣的做法與弊端

嘉賓介紹

高馳濤(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所關注的幾個點：

終端用戶體驗

應用架構映射

應用事務分析

深度應用診斷

數據分析報告

這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請求的前提下，關注超出響應閾值的請求。

步驟一、全部或部分請求通過hash算法，取得當前URI的hashkey；

步驟二、判斷請求是否為首次訪問，若是否，則執行；

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

步驟三、開始追蹤本次請求，采集本次請求的哈希值，并將此次采集的哈希值記錄在散列圖中；步驟四、判斷是否允許追蹤，若否，則執行步驟五，若是，則執行步驟六；

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

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

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

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

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

沒有開啟時，其實會是全數據采樣，也即樣本率為100% 為什么不采樣呢？ 因為我們信奉的金典是，基于業務的端到端。 只要想做到端到端的業務追蹤，任何形式的采樣，都可能直接導致某一個關鍵請求的缺失。或者換句話說，我們也在采樣，只不過樣本覆蓋率是100%。 這個算法大家可以參考一下，或許會對相類似的場景，有一些借鑒意義。

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

如何保持性能，包括數據采集性能，和數據處理性能 我們確實為性能付諸了極大的努力，比如數據格式，數據結構，傳輸協議，數據壓縮，等等，自豪地告訴大家，我們基本可以保證對用戶低于5%的性能損耗。如果打開了上面所述的算法開關，則可以將性能損耗有效降低到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)基礎架構最佳實踐

云計算服務（AWS）的介紹

隨著從0到千萬用戶的業務增長，通過aws的不同服務輕松地實現高性能和高可用的基礎架構。