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

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

[[188574]]

聽云研發(fā)副總裁廖雄杰

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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