前端監(jiān)控穩(wěn)定性數(shù)據(jù)剖析理論

大數(shù)據(jù)開(kāi)發(fā)工程師網(wǎng)易云微專業(yè)

download：https://www.51xuebc.com/thread-536-1-1.html

1 背景客服一站式工作臺(tái)集成了在線、熱線和工單三個(gè)中心應(yīng)用，支撐著自營(yíng)客服和 BPO 客服每天處置大量的會(huì)話信息，工作臺(tái)的穩(wěn)定性就顯得十分重要。接入前端監(jiān)控以來(lái)，我們堅(jiān)持每雙周跟進(jìn)工作臺(tái)以及客服幾個(gè)中心應(yīng)用的線上穩(wěn)定性狀況，盤繞頁(yè)面的訪問(wèn)狀況、JS 錯(cuò)誤率、資源加載異常狀況、API 接口勝利率、自定義業(yè)務(wù)模塊指標(biāo) 這五大監(jiān)控模塊，做了細(xì)致的數(shù)據(jù)剖析，從中發(fā)現(xiàn)了很多問(wèn)題并且經(jīng)過(guò)實(shí)時(shí)告警處理了潛在的問(wèn)題，也經(jīng)過(guò)數(shù)據(jù)剖析推進(jìn)了客服職場(chǎng)完善工作臺(tái)的運(yùn)轉(zhuǎn)環(huán)境。本文主要論述我們是如何經(jīng)過(guò)監(jiān)控穩(wěn)定性數(shù)據(jù)剖析來(lái)提升應(yīng)用系統(tǒng)的穩(wěn)定性。2 監(jiān)控的原理客服一站式工作臺(tái)接入監(jiān)控時(shí)經(jīng)過(guò)多方調(diào)研最終采用了 Arms 的監(jiān)控計(jì)劃，并基于 Arms 的監(jiān)控計(jì)劃，做了二次開(kāi)發(fā)，整體的監(jiān)控完成

Arms 提供的 SDK 功用比擬齊全，為滿足一些定制化的數(shù)據(jù)上報(bào)訴求、應(yīng)用數(shù)據(jù)權(quán)限管控以及控制上報(bào)本錢，客服域接入時(shí)基于 alife-logger 停止了二次封裝，對(duì)功用愈加的可控， 同時(shí)定期從阿里云平臺(tái)停止數(shù)據(jù)初始化和生成定制化報(bào)表。3 監(jiān)控的理論3.1 頁(yè)面 PV&UV 監(jiān)控場(chǎng)景PV 即頁(yè)面閱讀量，通常是權(quán)衡一個(gè)網(wǎng)站以至一個(gè)模塊運(yùn)用狀況的主要指標(biāo)。UV 即獨(dú)立訪客數(shù)，是指某站點(diǎn)被幾用戶訪問(wèn)過(guò)，以用戶登錄態(tài)作為統(tǒng)計(jì)根據(jù)。頁(yè)面的 PV 和 UV 很大水平上反應(yīng)了應(yīng)用各頁(yè)面功用的運(yùn)用狀況，能為產(chǎn)品功用優(yōu)化以及相關(guān)業(yè)務(wù)決策提供很好的數(shù)據(jù)支持 。我們針對(duì)客服域已接入監(jiān)控的應(yīng)用連續(xù)幾個(gè)迭代的 PV、UV 數(shù)據(jù)剖析，主要在如下事項(xiàng)起到了很好的推進(jìn)和決策作用：新功用上線效果剖析：經(jīng)過(guò)剖析頁(yè)面業(yè)務(wù)功用模塊 PV 相關(guān)數(shù)據(jù)，能夠剖析對(duì)應(yīng)上新功用的運(yùn)用狀況。若發(fā)現(xiàn)局部功用客戶觸達(dá)率較低，就能夠與業(yè)務(wù)溝通確認(rèn)是功用設(shè)計(jì)問(wèn)題還是上線功用布達(dá)問(wèn)題，快速做出運(yùn)營(yíng)戰(zhàn)略調(diào)整；下線無(wú)用模塊：經(jīng)過(guò)頁(yè)面運(yùn)用狀況剖析，對(duì)系統(tǒng)中訪問(wèn)量比擬少的頁(yè)面做了匯總剖析，同產(chǎn)品運(yùn)營(yíng)肯定之后，對(duì)在線客服管理系統(tǒng)和工單管理系統(tǒng)中的 9 個(gè)頁(yè)面做了下線處置，減少了頁(yè)面的維護(hù)本錢；支撐技術(shù)改造優(yōu)先級(jí)戰(zhàn)略：在技術(shù)棧遷移的過(guò)程中，能夠優(yōu)先對(duì)訪問(wèn)量比擬高的頁(yè)面停止遷移，普通頁(yè)面訪問(wèn)量高的對(duì)應(yīng)的需求迭代也比擬頻繁，經(jīng)過(guò)頁(yè)面訪問(wèn)排序，按優(yōu)先級(jí)去做遷移能夠提升整體投入的 ROI；助力系統(tǒng)體驗(yàn)優(yōu)化：經(jīng)過(guò)剖析較高 PV 頁(yè)面用戶訪問(wèn)鏈路，將取消訂單、創(chuàng)立賠付單等需求高頻但需求翻開(kāi)其他頁(yè)面操作的功用集成到客服聊天頁(yè)座席助手模塊，提升客服的工作效率。3.2 JS 錯(cuò)誤率監(jiān)控腳本錯(cuò)誤主要有兩類：語(yǔ)法錯(cuò)誤、運(yùn)轉(zhuǎn)時(shí)錯(cuò)誤。簡(jiǎn)單來(lái)說(shuō)就是用戶在一些特殊場(chǎng)景下閱讀器上報(bào) JS 的異常，以至?xí)纬上到y(tǒng)卡頓、頁(yè)面不可用等極端狀況，這會(huì)極大地降低用戶體驗(yàn)。因而我們經(jīng)過(guò)監(jiān)控系統(tǒng)對(duì)中心系統(tǒng)關(guān)鍵鏈路、關(guān)鍵指標(biāo)做好異常數(shù)據(jù)剖析設(shè)置監(jiān)控預(yù)警 ，到達(dá)設(shè)定的閾值則發(fā)送飛書(shū)或短信告警，值班同窗關(guān)注告警信息可以及時(shí)做出響應(yīng)，同時(shí)針對(duì)告警錯(cuò)誤內(nèi)容停止專項(xiàng)管理，到達(dá)效果如下：提升系統(tǒng)穩(wěn)定性: 合計(jì)處置 41 個(gè) JS 腳本異常管理，過(guò)程中發(fā)現(xiàn)異常業(yè)務(wù)場(chǎng)景并停止專項(xiàng)管理，很大水平上提升系統(tǒng)的穩(wěn)定性。發(fā)現(xiàn)躲藏問(wèn)題： 經(jīng)過(guò)監(jiān)控發(fā)現(xiàn) JS 錯(cuò)誤數(shù)增加，排查發(fā)現(xiàn)數(shù)量正在上升，實(shí)時(shí)聯(lián)絡(luò)一個(gè)正在觸發(fā)報(bào)錯(cuò)的客服遠(yuǎn)程，發(fā)現(xiàn)是接入的三方 SDK 發(fā)布新版版本，在特殊狀況會(huì)呈現(xiàn)報(bào)錯(cuò)，及時(shí)同步對(duì)應(yīng)的三方同窗停止矯正，有效防止因外部依賴發(fā)布帶來(lái)的躲藏問(wèn)題。3.3 API 懇求優(yōu)化監(jiān)控提供給用中每個(gè) API 的調(diào)用狀況，包括調(diào)用次數(shù)、調(diào)用勝利率、返回信息、調(diào)用勝利或失敗的均勻耗時(shí) 等數(shù)據(jù)。經(jīng)過(guò)剖析指定時(shí)間段內(nèi)應(yīng)用中一切 API 懇求數(shù)據(jù)，能夠深度發(fā)掘以下業(yè)務(wù)代碼完成和接口穩(wěn)定性一些相關(guān)的問(wèn)題：下線不用要調(diào)用： 排查過(guò)程中發(fā)現(xiàn)局部埋點(diǎn)調(diào)用頻次很高，但是實(shí)踐報(bào)表數(shù)據(jù)并未運(yùn)用起來(lái)，與業(yè)務(wù)溝通后發(fā)現(xiàn)為歷史遺留邏輯，目前已無(wú)用，所以停止下架。減少不用要的接口調(diào)用，釋放更多的閱讀器懇求資源。減少冗余調(diào)用： 共管理接口高頻調(diào)用管理調(diào)用 5 個(gè)，經(jīng)過(guò)剖析發(fā)現(xiàn)局部非中心功用的接口調(diào)用量較大，代碼走讀發(fā)現(xiàn)此局部接口為實(shí)時(shí)性請(qǐng)求不高枚舉列表的接口，能夠經(jīng)過(guò)前端緩存的方式減少接口調(diào)用次數(shù)，從而進(jìn)步用戶切換會(huì)話效率和減少效勞器的調(diào)用壓力。優(yōu)化技術(shù)計(jì)劃： 客服一站式工作臺(tái)存在長(zhǎng)鏈和短鏈調(diào)用分離的狀況，在我們?nèi)粘１O(jiān)控剖析中發(fā)現(xiàn)局部短鏈接口調(diào)用量大。經(jīng)過(guò)代碼走查和調(diào)用鏈路剖析發(fā)現(xiàn)由于業(yè)務(wù)功用需求，只需客服切換會(huì)話，就會(huì)拉取當(dāng)前會(huì)話最近五條音訊發(fā)起短鏈懇求，形成切換會(huì)話會(huì)有卡頓感，同時(shí)很容易呈現(xiàn)由于短鏈并發(fā)較多，頻繁切換回話后會(huì)呈現(xiàn)串線的狀況。所以與后端溝通后，將原先技術(shù)計(jì)劃內(nèi)的短鏈調(diào)用改為長(zhǎng)鏈音訊推送，很大水平上減少接口調(diào)用和音訊不實(shí)時(shí)的狀況，提升用戶體驗(yàn)和系統(tǒng)穩(wěn)定性。3.4 靜態(tài)資源加載異常優(yōu)化靜態(tài)資源加載分為頁(yè)面內(nèi)的圖片、CSS、JS 等 Assets 資源加載失敗。目前客服 BPO 職場(chǎng)均有平安管控，所以會(huì)呈現(xiàn)運(yùn)營(yíng)或者其他應(yīng)用上傳的靜態(tài)資源鏈接、圖片等資源，局部 BPO 打不開(kāi)的狀況，經(jīng)過(guò)前端監(jiān)控發(fā)現(xiàn)以下幾個(gè)問(wèn)題：圖片資源加載異常： 隨著一站式工作臺(tái)的業(yè)務(wù)拓展，陸續(xù)支持等其他租戶的客戶進(jìn)線。業(yè)務(wù)上線后，我們經(jīng)過(guò)監(jiān)控發(fā)現(xiàn)資源錯(cuò)誤數(shù)量呈現(xiàn)上漲，排查后確認(rèn)由于商品圖片等資源都是配置的 CDN 地址，需求 BPO 職場(chǎng)開(kāi)通網(wǎng)絡(luò)白名單客服才能夠看到指定的圖片資源。經(jīng)過(guò)監(jiān)控快速定位對(duì)應(yīng)的職場(chǎng)，同步對(duì)應(yīng)的職場(chǎng) IT 擔(dān)任人停止處置。運(yùn)營(yíng)配置錯(cuò)誤地址修正： 經(jīng)過(guò)監(jiān)控?cái)?shù)據(jù)剖析，發(fā)現(xiàn)不少報(bào)錯(cuò)的靜態(tài)資源地址中有飛書(shū)內(nèi)網(wǎng)地址和竹間遷移遺留資源的狀況，內(nèi)網(wǎng)地址外網(wǎng)是無(wú)法翻開(kāi)的，會(huì)給客服帶來(lái)不少攪擾。經(jīng)確以為運(yùn)營(yíng)遷移過(guò)程中存在遺漏形成，聯(lián)絡(luò)對(duì)應(yīng)的運(yùn)營(yíng)同窗停止專項(xiàng)管理，及時(shí)減少問(wèn)題影響面。3.5 頁(yè)面加載性能優(yōu)化頁(yè)面性能對(duì)用戶體驗(yàn)而言非常關(guān)鍵。每次重構(gòu)對(duì)頁(yè)面性能的提升，僅靠工程師開(kāi)發(fā)設(shè)備的測(cè)試數(shù)據(jù)是沒(méi)有壓服力的，需求有大量的真實(shí)數(shù)據(jù)用于考證；比方客服職場(chǎng)普遍反應(yīng)商品詳情頁(yè)面翻開(kāi)慢，影響到了客服的工作效率，體驗(yàn)很不好。為了明白詳細(xì)加載慢的點(diǎn)，我們針對(duì)頁(yè)面加載到頁(yè)面可用這個(gè)過(guò)程中以下幾個(gè)時(shí)間節(jié)點(diǎn)停止埋點(diǎn)：e_product_finish【總耗時(shí) ms】: 商品詳情頁(yè)面翻開(kāi)到一切資源均加載完成(包含圖片與懇求)耗時(shí)e_product_loadImg【加載圖片耗時(shí) ms】： 接口懇求回來(lái)到一切圖片加載完成耗時(shí)e_product_loadAndfetch【懇求耗時(shí) ms】： 商品詳情頁(yè)面加載靜態(tài)資源 &&發(fā)起懇求耗時(shí)經(jīng)過(guò)三天的線上數(shù)據(jù)剖析發(fā)現(xiàn)，大局部耗時(shí)在加載圖片耗時(shí)上。剖析耗時(shí)較長(zhǎng)的商品詳情上下鏈路，發(fā)現(xiàn)此類商品的圖片大多為 500kb+以至 1MB 左右的圖片 ，單個(gè)商品最多的狀況下商品輪播圖近 52 張圖，加上商品細(xì)節(jié)圖、商品穿搭效果圖等，單個(gè)商品詳情頁(yè)面初次翻開(kāi)居然需求加載 80+張圖片，關(guān)于閱讀器而言是災(zāi)難性的

所以經(jīng)過(guò)和產(chǎn)品磋商，我們針對(duì)商品詳情頁(yè)面停止了加載略縮圖交換高清大圖，同時(shí)減少初次加載圖片個(gè)數(shù)(初次只加載 5 張圖，點(diǎn)擊查看更多后才加載剩余局部圖片資源)等一系列的優(yōu)化戰(zhàn)略，很大水平上提升了商品詳情頁(yè)面的頁(yè)面體驗(yàn)。如圖下圖，為 12 月 19 日我們優(yōu)化上線后，圖片資源加載耗時(shí)均值趨向圖，有了很明顯的降落趨向。

4 監(jiān)控的效果接入監(jiān)控至今半年多的時(shí)間里，章魚(yú)一站式工作臺(tái)的穩(wěn)定性有了十分大的提升，經(jīng)過(guò)管理和告警以及推進(jìn)各職場(chǎng)運(yùn)轉(zhuǎn)環(huán)境的完善，大大減少了線上 TS 問(wèn)題的反應(yīng)以及防止了線上潛在問(wèn)題的發(fā)作。4.1 線上 TS 問(wèn)題的減少

接入監(jiān)控以來(lái)，經(jīng)過(guò)雙周穩(wěn)定性周會(huì)的管理，歸因于前端的 TS 問(wèn)題數(shù)量不時(shí)的減少，在雙十一和雙十二大促期間，也持續(xù)的穩(wěn)定在 5 個(gè)以下 。## 4.2 潛在問(wèn)題的發(fā)現(xiàn)經(jīng)過(guò)監(jiān)控訴警至少發(fā)現(xiàn)潛在的問(wèn)題不少于 5 處 ，經(jīng)過(guò)告警信息及時(shí)處理了潛在問(wèn)題的風(fēng)險(xiǎn)，防止了線上問(wèn)題的發(fā)作。這里舉一個(gè)十分典型的接口超時(shí)告警的例子：獲取用戶標(biāo)簽信息接口超時(shí)告警

經(jīng)過(guò)監(jiān)控訴警發(fā)現(xiàn)，查詢用戶標(biāo)簽信息接口 1 分鐘內(nèi) 1 個(gè)用戶屢次調(diào)用失敗 ，這個(gè)明顯是有問(wèn)題的。在跟網(wǎng)關(guān)和后端對(duì)接之后，發(fā)現(xiàn)主要的緣由是：一站式工作臺(tái)里面的在線和離線進(jìn)線的會(huì)話列表有用戶標(biāo)簽的顯現(xiàn)，當(dāng)用戶重新刷新閱讀器的時(shí)分，會(huì)同時(shí)調(diào)用在線和離線的用戶信息，離線用戶未及時(shí)關(guān)閉的話，會(huì)招致較多的超時(shí)短鏈懇求。固然該接口為非中心鏈路接口，但大量的短鏈調(diào)用是一個(gè)潛在的風(fēng)險(xiǎn)，后面跟產(chǎn)品磋商之后，將進(jìn)線列表的用戶標(biāo)簽刪除，取消接口懇求。4.3 推進(jìn)客服職場(chǎng)工作臺(tái)運(yùn)轉(zhuǎn)環(huán)境的穩(wěn)定客服職場(chǎng)的環(huán)境是十分復(fù)雜的，閱讀器運(yùn)用的多樣性以及不一樣的版本都會(huì)帶來(lái)不可預(yù)知的問(wèn)題，招致前期很多的客服反應(yīng)，研發(fā)同窗投入了大量的時(shí)間去做問(wèn)題定位，最終發(fā)現(xiàn)是閱讀器版本過(guò)低招致。所以針對(duì)這個(gè)狀況，我們定期匯總了閱讀器版本的運(yùn)用狀況，告知給業(yè)務(wù)，讓業(yè)務(wù)推進(jìn)各職場(chǎng)閱讀器版本的晉級(jí)和統(tǒng)一。

從監(jiān)控?cái)?shù)據(jù)來(lái)看，存在火狐閱讀器、搜狗閱讀器、QQ 閱讀器和 android 手機(jī)閱讀器 ，關(guān)于這些閱讀器，根本都存在一些兼容性問(wèn)題，由于一站式工作臺(tái)里面的技術(shù)晉級(jí)用了較多的閱讀器新特性來(lái)對(duì)業(yè)務(wù)模塊做了重構(gòu)，故關(guān)于非 chrome 閱讀器存在兼容性問(wèn)題，這也是為什么有些職場(chǎng)客服反應(yīng)如工單詳情打不開(kāi)、訂單詳情翻開(kāi)異常等問(wèn)題。chrome 閱讀器低版本數(shù)據(jù)匯總：

在幾次推進(jìn)之后，目前因閱讀器版本反應(yīng)的問(wèn)題曾經(jīng)大大減少，很大水平減少研發(fā)在閱讀器版本問(wèn)題排查的時(shí)間。4.4 中心性能指標(biāo)的監(jiān)控目前除了上面商品詳情頁(yè)的監(jiān)控指標(biāo)，我們還對(duì)工單詳情頁(yè)面和訂單詳情頁(yè)面的渲染時(shí)間以及音訊接納和發(fā)送的耗時(shí)做了監(jiān)控，當(dāng)超越一定的閾值，就會(huì)上報(bào)告警信息。目前工單詳情和訂單詳情頁(yè)面經(jīng)過(guò)屢次的重構(gòu)，整體的渲染耗時(shí)曾經(jīng)穩(wěn)定在 500 毫秒左右，做到了秒開(kāi)，詳細(xì)能夠看近一周的渲染趨向：近 7 天工單詳情頁(yè)面渲染趨向：

近 7 天訂單詳情頁(yè)面渲染趨向：

我們也抵消息接納與發(fā)送耗時(shí)中心鏈路做了重構(gòu)，目前也沒(méi)有反應(yīng)音訊接納和發(fā)送耗時(shí)帶來(lái)的延遲卡頓問(wèn)題。

關(guān)于接納音訊的告警我們只會(huì)對(duì)超越 700 毫秒的時(shí)分做告警，由于大局部的音訊接納和發(fā)送都在 100 毫秒以內(nèi)，客服是無(wú)感知的。5 總結(jié)客服各系統(tǒng)自接入監(jiān)控至今也有半年多的時(shí)間，監(jiān)控是我們系統(tǒng)發(fā)布上線的定心丸，同時(shí)經(jīng)過(guò)監(jiān)控?cái)?shù)據(jù)也可以協(xié)助我們看出不少系統(tǒng)存在的問(wèn)題，為我們的系統(tǒng)穩(wěn)定性提升以及系統(tǒng)體驗(yàn)優(yōu)化做出不少奉獻(xiàn)。好音訊是我們得物自研監(jiān)控平臺(tái)也正逐漸建立完善中 ，目前前端平臺(tái)、穩(wěn)定性監(jiān)控平臺(tái)和效率工程一同協(xié)作開(kāi)發(fā)的前端監(jiān)控產(chǎn)品初版曾經(jīng)完成，客服前端這邊也逐漸將應(yīng)用遷移至自研的監(jiān)控平臺(tái)，置信隨著自研監(jiān)控才能的的不時(shí)完善，我們可以在前端監(jiān)控這一塊獲得更好的成果。