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

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

[[188574]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這是真實的用戶體驗，然后在這里可以看到網(wǎng)絡(luò)的切片情況，看到網(wǎng)絡(luò)包括什么，可能比較關(guān)心的DS解析化了多長時間，建立連接的時候用了多長時間，然后會有首報時間，就是服務(wù)服務(wù)響應(yīng)的時間?；旧峡梢远ㄎ怀鰜淼降资蔷W(wǎng)絡(luò)端的問題，還是服務(wù)器端的問題。如果是服務(wù)器端的問題，可以通過其他技術(shù)手段，剛才說了通過STM監(jiān)控方式，網(wǎng)絡(luò)切片，其他的像建連比較正常，可以判斷由于服務(wù)器內(nèi)部發(fā)生阻塞，導(dǎo)致阻塞了一段時間向客戶端發(fā)送一個首報，我們會把一次完整的請求到它響應(yīng)回來，網(wǎng)絡(luò)不同的階段都可以做出非常詳細(xì)的切片，這是網(wǎng)絡(luò)的一部分。

剛才說了ADTD，這一塊我們可以做什么。在塊展示了后端訪問到不同的服務(wù)，服務(wù)跟服務(wù)之間的交互，服務(wù)跟數(shù)據(jù)庫和MQ等等，通過拓?fù)涞姆绞娇梢宰詣影l(fā)現(xiàn)出來。應(yīng)該說這個圖運維也是比較喜聞樂見的，畢竟架構(gòu)越來越復(fù)雜，基本上當(dāng)應(yīng)用越來越復(fù)雜的時候，更多時候會發(fā)現(xiàn)很難去掌控它后端的架構(gòu)。比如說應(yīng)用跟應(yīng)用之間關(guān)系是怎么交互的，應(yīng)用跟組件之間它們的依賴關(guān)系是怎么交互的，包括每一個服務(wù)，每一個組件，它的調(diào)用次數(shù)、吞吐量和錯誤率，這些都是可以以直觀的方式展現(xiàn)出來。

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

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

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

后臺應(yīng)用邏輯拓?fù)?，包括拓?fù)淅锩婷恳粋€組件和性能的監(jiān)控是通過ADTD的方式，包括代碼級的監(jiān)控可以監(jiān)控到應(yīng)用過程，每一個請求有多少次，它的平均時間是多少。

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

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

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

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

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

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

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

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

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

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

包括后端的服務(wù)跟服務(wù)之間，服務(wù)跟數(shù)據(jù)庫之間。主要是服務(wù)跟服務(wù)之間，我們說跨應(yīng)用，包括要實現(xiàn)服務(wù)跟服務(wù)之間的追蹤，API微服務(wù)可能用的比較多一點。當(dāng)我們拿到了這么多的數(shù)據(jù)之后，可以對它調(diào)用鏈的追蹤方式，所有的請求從A服務(wù)到B服務(wù)、C服務(wù)，所有的調(diào)用鏈都可以描述出來，當(dāng)多個服務(wù)同時報警的時候，如何拿這些數(shù)據(jù)對它問題的根因，到底是什么原因?qū)е碌模鲆粋€根因分析。

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

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

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