·面對APP出現(xiàn)緩慢耗時(shí)過長，你是否苦于無法即時(shí)定位問題的出處？

·面對網(wǎng)站的訪問緩慢，你是否糾結(jié)于是網(wǎng)絡(luò)原因還是后臺程序原因造成的？

·面對頁面性能耗損嚴(yán)重，你是否無法定位是頁面結(jié)構(gòu)問題還是資源請求過慢？

·面對復(fù)雜的跨系統(tǒng)的性能問題，是否無法精準(zhǔn)找出問題的根源？

沒關(guān)系，現(xiàn)在有聽云APM全棧溯源來幫你，它是國內(nèi)首家實(shí)現(xiàn)全端、跨應(yīng)用監(jiān)控的功能，能夠幫助DevOps快速實(shí)現(xiàn)不同業(yè)務(wù)邏輯下的性能排障。

什么是全棧溯源？

在復(fù)雜的應(yīng)用環(huán)境下，精確定位并判斷網(wǎng)絡(luò)、移動端、瀏覽器端、服務(wù)端性能問題根源的技術(shù)手段。其中，它包括：

1、從移動端到服務(wù)端的性能溯源

2、從網(wǎng)絡(luò)到服務(wù)端的性能溯源

3、從瀏覽器端到服務(wù)端的性能溯源

4、服務(wù)端跨語言跨應(yīng)用的性能溯源

全棧溯源對DevOps的價(jià)值

1、降低跨部門排障溝通成本

2、從3天到5分鐘快速追溯性能問題根源

3、性能問題界定，協(xié)助運(yùn)維明確責(zé)任，協(xié)助研發(fā)修改問題

4、完整業(yè)務(wù)調(diào)用鏈跟蹤（業(yè)務(wù)、運(yùn)維、研發(fā)）

全棧溯源必要條件

在部署聽云Server 的同時(shí)需部署聽云App/Network/Browser其中一款產(chǎn)品，打通雙端。

如何使用全棧溯源？

從移動端到服務(wù)端的性能溯源

［1］場景：

在一次http請求的過程當(dāng)中，請求所消耗的時(shí)間可能是在不同的步驟發(fā)生的，即耗時(shí)過長可能發(fā)生在建連時(shí)間或服務(wù)器消耗上。那么我們?nèi)绾畏纸鈺r(shí)間，以便知道一次網(wǎng)絡(luò)請求的時(shí)間都消耗在什么地方了？在這方面，全棧溯源可以直接將一次網(wǎng)絡(luò)請求耗時(shí)細(xì)化到服務(wù)端所消耗的時(shí)間。

［2］解決流程：

 

·選中某一個(gè)具體的URL,當(dāng)發(fā)起請求的APP同時(shí)部署聽云App和聽云Server探針后，便可以進(jìn)行全棧溯源的操作

·將該URL通過跳轉(zhuǎn)按鈕跳轉(zhuǎn)到Web應(yīng)用過程，可以在POST請求跳轉(zhuǎn)到服務(wù)端的部分上看到服務(wù)端消耗時(shí)間

·可以看到具體的耗時(shí)部分，找到問題根源

從網(wǎng)絡(luò)到服務(wù)端的性能溯源

［1］場景：

有時(shí)候網(wǎng)站發(fā)生的性能問題并不是由于網(wǎng)站、網(wǎng)絡(luò)、運(yùn)營商等前端造成的，而是由于后端服務(wù)器產(chǎn)生的影響。

［2］解決流程：

 全棧溯源可以關(guān)聯(lián)聽云Network與聽云Server 2個(gè)產(chǎn)品的監(jiān)測數(shù)據(jù)，實(shí)現(xiàn)完整的端到端的監(jiān)測解決方案。當(dāng)監(jiān)測數(shù)據(jù)發(fā)生異常時(shí)，聽云Network可以定位到防火墻以外的問題，關(guān)聯(lián)聽云Server后可以更好的定位到服務(wù)端的問題，幫助用戶更加快速的定位問題的原因。

·聽云Network對支持跨應(yīng)用追蹤的任務(wù)會自動進(jìn)行關(guān)聯(lián)，任務(wù)列表中進(jìn)行提示

·關(guān)聯(lián)成功后會增加服務(wù)器端指標(biāo)排隊(duì)時(shí)間（Server）和服務(wù)器響應(yīng)時(shí)間（Server）

·關(guān)聯(lián)成功的元素會在元素瀑布圖中進(jìn)行標(biāo)記，可以直接跳轉(zhuǎn)到Server下對應(yīng)的web應(yīng)用過程

·直接跳轉(zhuǎn)到主元素的web應(yīng)用過程

·對于應(yīng)用響應(yīng)時(shí)間超于閾值的會觸發(fā)Server的慢應(yīng)用過程追蹤

·慢應(yīng)用過程可以直接追蹤到Server中的數(shù)據(jù)進(jìn)行分析

·

從瀏覽器端到服務(wù)端的性能溯源

［1］場景：

H5發(fā)展日漸迅猛，運(yùn)行環(huán)境也更加復(fù)雜，有時(shí)會發(fā)現(xiàn)HTML5頁面的渲染緩慢，AJAX時(shí)間過長都不一定是HTML5本身的問題，有可能是后端引發(fā)的性能問題。

［2］解決流程：

 

一般應(yīng)用的性能損耗會發(fā)生在網(wǎng)頁前端、網(wǎng)絡(luò)以及后端服務(wù)器。聽云Browser能夠監(jiān)測網(wǎng)頁訪問的性能情況，配合聽云Server可以了解到服務(wù)器端響應(yīng)的性能損耗。

·在聽云Browser應(yīng)用列表中采用自動嵌碼Server探針的，可以直接查看聽云Server應(yīng)用的情報(bào)匯總

·頁面分析和AJAX請求中添加到Server的Web應(yīng)用過程的查看

·直接跳轉(zhuǎn)到停運(yùn)Server控制臺下對應(yīng)的web應(yīng)用過程進(jìn)行分析

·在聽云Browser的慢頁面追蹤中，如果元素超過閾值可以繼續(xù)進(jìn)行Server的慢應(yīng)用過程追蹤

·可以繼續(xù)定位到聽云Server慢應(yīng)用過程追蹤詳情

 

服務(wù)端跨系統(tǒng)、業(yè)務(wù)的性能溯源

［1］場景：

無論是從互聯(lián)網(wǎng)行業(yè)還是傳統(tǒng)的IT行業(yè)來看，當(dāng)前的系統(tǒng)架構(gòu)都變得越來越復(fù)雜。從最簡單的互聯(lián)網(wǎng)架構(gòu)：前端做分流，后端做業(yè)務(wù)，到傳統(tǒng)行業(yè)擁有自己的前端、邏輯層、數(shù)據(jù)層，以及系統(tǒng)間的調(diào)用、通信越來越多，都導(dǎo)致了一個(gè)問題：發(fā)現(xiàn)問題的地方和真正導(dǎo)致這個(gè)問題的出處存在了一定的距離，并且在未來距離會越來越大。

比如發(fā)現(xiàn)了A系統(tǒng)響應(yīng)時(shí)間非常久，經(jīng)調(diào)查A系統(tǒng)本身沒有問題，那么很可能便是A系統(tǒng)在調(diào)用別的系統(tǒng)時(shí)引發(fā)響應(yīng)時(shí)間過長。而全棧溯源便可以很好地解決這個(gè)問題，無論是調(diào)用鏈多么復(fù)雜，都能根據(jù)業(yè)務(wù)進(jìn)行有效追蹤，從發(fā)現(xiàn)問題的入口一直跟蹤到產(chǎn)生問題的出處。同時(shí)，聽云Server能夠完美接入聽云App、聽云Network、聽云Browser產(chǎn)品，通過連通聽云Server，定位到其他的應(yīng)用上、數(shù)據(jù)庫或者中間件上的問題。

［2］解決流程：

搭建模擬的系統(tǒng)，共三層：（1）前端：用戶注冊層；（2）業(yè)務(wù)層；（3）用戶校驗(yàn)系統(tǒng)

 

·當(dāng)從前端發(fā)現(xiàn)用戶注冊的時(shí)間非常久，通過查看 Web應(yīng)用過程，發(fā)現(xiàn)Web應(yīng)用過程慢應(yīng)用追蹤記錄

·經(jīng)查看前端服務(wù)器發(fā)現(xiàn)，調(diào)用耗時(shí)久的原因在于所有的時(shí)間都消耗在另一臺服務(wù)器上，即后端服務(wù)器（用戶管理中心服務(wù)器）

·經(jīng)追蹤發(fā)現(xiàn)，該服務(wù)器大面積運(yùn)行的耗時(shí)都在另一臺服務(wù)器上，即用戶管理服務(wù)器性能無礙，問題發(fā)生在驗(yàn)證服務(wù)器上，點(diǎn)擊進(jìn)行追蹤下去，發(fā)現(xiàn)在追蹤詳情上可以看到存在一條慢SQL，該SQL語句執(zhí)行時(shí)間非常久

·針對該SQL進(jìn)行優(yōu)化，解決問題

全棧溯源可以將所有你能想象得到碎片化的問題完美整合，以一種串行的方式去定位問題，并且無論從研發(fā)人員還是運(yùn)維人員角度去利用聽云全棧溯源去解決問題，都可以非常直接、準(zhǔn)確定位問題出處，高效將問題解決。