【51CTO.com原創稿件】2017年4月14日－15日，由51CTO主辦的WOTA全球架構與運維技術峰會在北京富力萬麗酒店隆重召開。本次WOTA設置了15大前沿熱點技術論壇，60+來自Google、LinkedIn、Airbnb、百度、阿里巴巴、騰訊等海內外一線互聯網公司的技術大咖將帶來超過50個歷經沉淀的架構實戰心得與成功經驗分享案例，攜手打造歷時2天的行業***技術盛會。

4月14日上午WOTA2017主會場，聽云研發副總裁廖雄杰進行了主題為《全棧APM--打造端到云的全方位監控體系》的精彩演講。以下是演講實錄，讓我們先睹為快！ 

[[188574]]

聽云研發副總裁廖雄杰

很高興在這里跟大家見面，我今天介紹的是APM五方面的工具集和操作的方法。在運維的場景，以及產品應用和交互的場景里可能會遇到一些性能問題，也可能是產品運營的階段，因為這些問題是直接影響用戶最終的體驗。

對于大型的應用來說，我們也可能涉及到很多的環節，首先我們會從最終用戶APP或者PC瀏覽器的方式訪問，最終用戶這一端就會有些問題產生。最終用戶到我們服務器之間可能有網絡CDN和云中間的環節，服務器內部會有服務器和服務器之間的環節要發生交互，以及各種組件都要發生交互。

尤其是現在很多公司在推行微服務化，以及其他的服務化的架構。在這種架構下，我們遇到一個問題，就是你的架構層級越來越復雜，監控對于運維來說，它的體量難度和復雜度也會隨之加大。

然而出現問題之后怎么去監控這個環節的問題，我們要監控網絡另一端，需要CDN或者是本地運營商，有可能是用戶自己網絡環境的問題，所有的問題需要定位出來，到底是哪方面的問題，哪些需要去優化和解決。對于服務器內部的各個組件都有可能發生的問題。

剛才AWS的張俠總介紹了AWS云的概念，這幾年云對運維界來說是很大的福音，現在聽云全部的應用都在云上面部署。應該說云解放了運維很大一部分的經歷，把我們從冷冰冰的機房里面解放出來，現在很多運維基本上不用我們再三天兩頭扛著服務器滿大街跑。

今天介紹APM概念，對于運維來說怎么樣了解應用的各個環節，當遇到問題和出現問題的時候，怎樣進行排查。大家猛一看到這個是研發團隊相關人員干的事情，實際上這個問題對于運維人員來說是很大的苦惱，當出現問題的時候首先肯定是運維這邊首先要介入，你要定位到底是基礎環境出現問題，還是應用本身內部出現問題。只有把權責定位清楚以后，你才有可能把問題交給研發或者留給運維處理。

今天首先介紹一下APM幾大功能緯度，其實也是APM的組件，我們實施APM幾種常用的方法。

首先是DEM，不管是從外部或者是內部對應用本身進行可用性和性能的監控，這是我們最直觀的監控。應該說我們的用戶出現問題的時候，首先它應該也是跟這個有關系。我們首先把這個狀態持續監控出來，我們才有可能再往后面排查有沒有更深層次的問題。DEM是比較大的方面和功能緯度，這里面主要的工具集，分成兩種，一種是RUM，這個是真實用戶的性能監控。通常會基于有Web端和移動端，用戶訪問的時候客戶集中在Web瀏覽器或者是移動端。從每一個正式用戶向應用發生請求的時候，在這個過程當中通過一定的方式，比如像瀏覽器通過嵌碼的方式，移動端有更復雜的嵌碼的方式，這個需要自動的嵌碼，因為這個不能在研發的接單把監控代碼嵌進去，這兩個嵌碼的過程應該完全是自動化的。

首先是真實用戶的監測，另外一個方式跟它相對應的是STM模擬事務監控，這個跟剛才那個有什么不太一樣的地方呢？真實用戶的監測，拿Web瀏覽器舉例子有什么樣的缺陷，表現上來看是從真實用戶的角度發起監測，這肯定是最合理的，出問題的時候我們最關注的也是用戶。但是這種監測方式有比較致命的缺陷，我們說監控首先可用性和性能肯定都需要監控起來。

如果是Web瀏覽器的方式，目前絕大部分都是GS的方式就是嵌碼，這意味著你的瀏覽器，你當前的頁面至少需要正常的請求和完成，之后你的GS才有可能被正常運行。如果在這個過程當中出現網絡異常或者只是頁面GS的錯誤，導致你的監控腳本根本沒有辦法加載或者運行，所以有一個很大的問題，當它出現異常的時候，你通過這種方式監控是比較困難的。所以STM在這方面有比較大的優勢，STM它是模擬用戶，你可以有針對性的，在機房或者也可以在最終用戶，在最終的機器上面部署一些機器人的節點，它可能不是真實的用戶，但是它跟真實用戶一樣，它其實是最終用戶的訪問，你可以控制瀏覽器把網絡事件和性能的各種指標抓出來，這是比較重要的兩個監測方式，一個是DEM，一個是RUM，一個是STM。

然后，APM的第二大功能是DATD，這個是什么意思呢？剛才說從最終用戶的角度，不管是正式用戶或者是模擬的監測，它都是最終用戶的角度來觀察應用。所以這個方式的應用內部，比如訪問數據庫或者說訪問MQ，這種是DEM無法監測的，因為它在用戶的遠端看不到，最多到網絡這一端，到服務器內部就看不到了。所以這里面需要用到第二個功能范疇，就是ADTD，你需要描述服務器內部，尤其是微服務架構，A服務于B服務之間的調用關系是什么樣的，調用的過程中有沒有問題，有問題到底是A服務出現問題，還是B服務出現問題。所以這些追溯都應該在這里面被描述出來，如果數據不描繪出來，監控就無從談起。

對于第二大領域來說還有一個比較重要的特性，就是除了描述它們之間的關聯關系，還有性能之外，一旦發現問題可以深度的鉆取，最終用戶訪問到應用內部的時候，應用內部看到它進來，后端與其他服務之間的交互，跟數據庫、緩存、MQ之間的交互，所有的組件都應該被鉆取出來，否則的話最終看到的是服務出現了問題，但是問題出在哪里不知道，所以深度鉆取也是必須要有的。當它出現問題的時候，其實我們有手段做到行級代碼的分析，是哪一行代碼出現了問題。因為在應用內部，通常通過合理的方式，通過代碼植入的方式，我們可以拿到代碼出現的信息。當出現問題的時候甚至可以定義到行級代碼的區別，這個對于運維來說，這應該是非常有用的工具。因為不需要了解每一個應用開發的細節，也就可以很快的把問題定位出來，所有的這些都是工具化的。

前面主要介紹的是數據的來源，我們怎么抓取這些數據，有了這些數據之后，我們可以通過機器學習和統計推斷的手段發現數據性能異常的來源或者是根源。我們認為經常有報警，你是A服務、B服務、C服務全部發生報警到底是什么問題，這個時候需要追溯根源，可以通過統計學習的方法、機器學習的方法來分析這些數據得出來的結論，這是后期的數據加工的問題。

剛才給大家介紹了一下APM主要的實現方式，我們把APM主要的實現方式，包括它的功能緯度都描述了一下。現在我們實際看一下，我們能夠做到要全棧，我們通過這個圖看一下，我們每個點能做什么呢？我們的APP可能有原生的APP，也有可能是H5開發的，在你的APP內部工作，這一塊是RUM的APP的一部分，分為兩部分，這兩個技術手段都完全可以做到從最終端監測，前端看到網絡性能的情況，這些都可以做到。包括前端性能的情況，比如說有一段腳本執行的有問題，你至少可以定位出來大概在哪一塊，瀏覽器渲染的時候有問題，在前端可以監測出來。

中間這一部分是網絡這一層，是STM工作的區域，可以***程度的發現一些網絡的問題，它為什么是網絡放在這一端，模擬的意味著我們可以把它部署在任何地方。比如說我們部署在機房里面，你可以部署在最終用戶的機器上面，你的機房和最終用戶，你也可以按你關心的區域運營商，按你的比例分配監測的資源，你不用像正式用戶一樣返回多少是多少。可以利用這些時間做更多的事情，而且有一個好處，就是STM的方式，通常它的監控方式，本質上是我們開發一個專門的A政策，這個意味著你可以獲取到瀏覽器更多的事情，我們知道GS工作在真實用戶的瀏覽器里面，你能做的事情其實是比較少的。你想獲取到的很多數據，可能因為安全或者是技術方面的限制，你是無法實現的。在STM這一塊可以抓到盡可能細的數據，可以把問題分析的更透徹，通過STM你可以定位，它是CDN的問題，還是本地網絡的問題，還是本地的運營商網絡有問題，還是說骨干網絡出現了問題，這些都可以定位出來。可以通過你的節點在不同的位置部署，這樣就可以區分很多的緯度。

后面服務器內部，包括云內部服務器的應用是ADTD工作的領域，可以監測應用，理論上來說從應用發起訪問的地方，訪問本身是可以監控的。數據通過JDBC監控，把監控代碼嵌上，訪問的數據庫就出來了。所有的嵌碼應該說在技術上都是統一化的，不像我們說的可能有很多專業的監控，比如說數據庫每一種都是針對不同的協議和不同的服務器部署。對于APM的實現方式，一般情況下我們會通過統一的方式實現，因為應用出現問題的時候，最終關心的是應用向某個組件發起訪問的時候到底有沒有問題，有問題你能給我定位出來就可以了。

這是基本的拓撲圖，***個看到的是概覽的情況。第二個是真實用戶的情況，這個是IOS的應用，可以看到它的每一個網絡訪問請求，它的曲線有一個時間段，它的訪問時間標上去了，通過分析大量的真實用戶的數據，然后把這個數據通過圖表的方式、可視化的方式展現出來，這個符合運維的基本原則。所有的監控數據都應該是指標度量出來之后，然后可視化出來，這樣的話才能成為一個工具。

這是真實的用戶體驗，然后在這里可以看到網絡的切片情況，看到網絡包括什么，可能比較關心的DS解析化了多長時間，建立連接的時候用了多長時間，然后會有首報時間，就是服務服務響應的時間。基本上可以定位出來到底是網絡端的問題，還是服務器端的問題。如果是服務器端的問題，可以通過其他技術手段，剛才說了通過STM監控方式，網絡切片，其他的像建連比較正常，可以判斷由于服務器內部發生阻塞，導致阻塞了一段時間向客戶端發送一個首報，我們會把一次完整的請求到它響應回來，網絡不同的階段都可以做出非常詳細的切片，這是網絡的一部分。

剛才說了ADTD，這一塊我們可以做什么。在塊展示了后端訪問到不同的服務，服務跟服務之間的交互，服務跟數據庫和MQ等等，通過拓撲的方式可以自動發現出來。應該說這個圖運維也是比較喜聞樂見的，畢竟架構越來越復雜，基本上當應用越來越復雜的時候，更多時候會發現很難去掌控它后端的架構。比如說應用跟應用之間關系是怎么交互的，應用跟組件之間它們的依賴關系是怎么交互的，包括每一個服務，每一個組件，它的調用次數、吞吐量和錯誤率，這些都是可以以直觀的方式展現出來。

再其次是運維和研發比較關注的，當出現問題的時候，肯定是想知道到底是哪行代碼出現了問題。***一步，當你定位問題之后，我們可以通過提前把代碼調用，以及其他的信息，如果是SQL調出可以自動抓取出來，協助你后面的開發進行進一步的分析。

比如說這里簡單的展示不同的調用組件，它們之間占用的時間。左邊那個圖展現了不同的組件它的調用數，以及每一個組件調用時間的比例。

現在我們簡單總結一下，現在我們說全棧APM簡單的幾步，真實用戶性能，這邊用的是DEM，主要還是RUM。在網絡切片這塊，我們主要用到DEM里面的STM就是模擬監測的方式，網絡切片做的是最細的。另外一個是NPM沒有介紹，可能也有運維團隊有過這樣的經驗，NPM你可以把你機房里面的交換機，通過專門的軟件分析流量的每一個包，然后從流量的包里面分析它的性能和各個之間的關系。但是這個比較局限，從服務器拿到流量包可能有很多信息已經丟失了，你只有一個包數據，它能分析出來的內容相對來說比較有限一點。

后臺應用邏輯拓撲，包括拓撲里面每一個組件和性能的監控是通過ADTD的方式，包括代碼級的監控可以監控到應用過程，每一個請求有多少次，它的平均時間是多少。

介紹完全棧APM，我相信對于運維應該都會有一個強迫癥。就是剛才說了這么多監控手段，我們能不能把它串起來做成一站式的監控。比如說剛才說從真實用戶到服務器，到我們后端的組件。到真實用戶發現問題的時候，能不能從真實用戶一步一步直接排查到***端，***的定位到底是網絡端的問題，還是服務器端的問題。如果是服務器端的問題，它到底是哪個組件的問題。包括如果是服務器端，后端某一個服務調用時候出現了問題，導致前端的響應變慢，能不能一站式的暴露出來，并且包括剛才說的行級代碼的分析，這些方式都可以結合起來用。

剛才說了Web的RUB，我們怎么樣到服務器，就是瀏覽器到服務器怎么樣追溯一個問題。包括關聯它們性能之間的關系，首先我們從瀏覽器的監控里面，監控方式后面會稍微介紹一下，我們監控到一個請求它的響應時間比較長。

我們看下面這個圖，我們把它分解成服務器端的響應時間，以及網絡層以及前端的渲染。展示的時候首先把服務器端的時間單獨作為一個指標，在這個圖上你可以看出來，它到底是服務器端發生的問題，還是前端的網絡發生了問題。

我們可以通過鉆取的方式直接鉆取到后端關聯出問題的應用，這個已經到達服務器端對應的請求，這個請求點開之后，我們會看到某一個組件，它是往另外一個后端的服務，它的響應時間比較高，我們可以一次鉆取把它全都關聯出來。

我們再往后看的話，既然已經到達服務器那端。其實后端應該沒有必要詳細說了，因為基本上大部分的ADTD里面的東西，剛才已經簡單介紹了，因為已經到達服務器后端，再往下鉆取可以發現到底是哪一個組件，這個是瀏覽器詳細的分析。每一個元素我們頁面瀏覽響應的時間都可以展示出來，我們看到其中有一個元素時間比較長。然后我們給它從元素的級別開始，每一個元素我們可以往后鉆取。比如說請求比較慢，它的后端可能對應另外一個應用，能不能從這里鉆取到后端的應用里面去。

鉆取到后端的應用之后，我們可以通過ADTD后端的分析。比如說我們可以看到它請求后端再后端另外的URL，請求的時候發生了問題，響應時間比較長。再往后看，我們可以看到它到底是哪個方法，哪一行代碼出現了問題。

具體的實現方式簡單介紹一下，其實也比較簡單，我們要把瀏覽器和服務器端，首先它會自動嵌碼，服務器端也會自動嵌碼。嵌完碼之后，我們要干的事情，從這個請求，從瀏覽器端一直發到服務器端，再從服務器端回到瀏覽器端。我們把請求和響應的過程用一個東西放到某一個地方傳到服務器，然后再傳回來就可以了。對于瀏覽器的方式，我們可以直接把Ajax改掉，但是主頁面的請求你沒有辦法改HTTP頭的，但是有什么辦法嗎？服務器端我們也是通過嵌碼的方式嵌進去的，事實上我們可以在服務器端嵌碼的時候直接攔截JSP、PHP編譯的過程，我們直接輸出一些可以關聯起來的信息。比如說生成一個東西放到頁面里面，然后帶回來就可以了，總會有一些技術的手段實現這個過程。所以我們有辦法把它關聯起來。

Java可以自動修改，把我們要干的事情，其實在一個函數的前后打上時間傳上來就可以了。包括出現異常的時候，也可以監測出來傳到服務器這端來，服務器端最終是通過這套代碼攔截的方式，訪問數據庫，你最終都是通過調用API某一個函數實現的，所以我們要攔截的就是這樣一些函數。

瀏覽器就更簡單了，想必大家應該都會看過類似的GS的代碼，我們很多廣告分析，以及用戶分析，很多網站都有，對于APM來說我們要獲取它的性能，在很早以前是直接用GS的方式，但也有很多時候是獲取不到的。比如說在瀏覽器的內部，它沒有通過GS的API開放出來。在2011年、2012年之后W3C把這兩個標準開放出來，大部分主流的瀏覽器也都實現了這樣的標準，其實實現的方式比較簡單，簡單看一下它有一個Navigation timing的接口，它是在哪個時間開始，在哪個時間結束，對應的解析的時間、渲染的時間和建鏈的時間都可以拿到。我們把代碼注入進去之后，你可以拿到所有你要的前端網絡，以及前端的解析和性能監控的數據，完了之后對它做一些簡單的分析，這樣一個監控的界面就出來了。

剛才我們大概介紹了Browser到Server，怎么做一站式APM的溯源。其實對于APP來講也有類似的方式，監控數據都拿到了，代碼都嵌入進去了，肯定有技術手段。

包括后端的服務跟服務之間，服務跟數據庫之間。主要是服務跟服務之間，我們說跨應用，包括要實現服務跟服務之間的追蹤，API微服務可能用的比較多一點。當我們拿到了這么多的數據之后，可以對它調用鏈的追蹤方式，所有的請求從A服務到B服務、C服務，所有的調用鏈都可以描述出來，當多個服務同時報警的時候，如何拿這些數據對它問題的根因，到底是什么原因導致的，做一個根因分析。

本次給大家介紹了APM使用場景，包括APM套件里面主要的工具，APM套件里面幾個主要的實現方式。我的演講就到這里，謝謝大家。

51CTO記者將持續為您帶來WOTA2017全球運維與架構技術峰會前方精彩報道，敬請期待！

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】