引言
隨著數(shù)字化時(shí)代的到來寸痢，各個(gè)行業(yè)的應(yīng)用系統(tǒng)從傳統(tǒng)私有化部署逐漸轉(zhuǎn)向公有云呀洲、行業(yè)云、微服務(wù)啼止，這種變遷給運(yùn)維部門和應(yīng)用部門均帶來了較大的挑戰(zhàn)道逗。基于當(dāng)前企業(yè) IT 運(yùn)維均為多部門負(fù)責(zé)献烦，且使用多種運(yùn)維工具滓窍，因此，當(dāng)業(yè)務(wù)出現(xiàn)問題時(shí)很難快速定位故障根源巩那。而隨著業(yè)務(wù)上云吏夯，云平臺(tái)運(yùn)維和應(yīng)用運(yùn)維的責(zé)任歸屬不同，業(yè)務(wù)方（租戶）只負(fù)責(zé)云平臺(tái)之上運(yùn)維即横，若是要對(duì)業(yè)務(wù)體驗(yàn)全鏈路負(fù)責(zé)噪生，就會(huì)導(dǎo)致有責(zé)任沒手段。同時(shí)东囚，容器微服務(wù)架構(gòu)應(yīng)用后的業(yè)務(wù)之間的訪問關(guān)系更加復(fù)雜跺嗽，也會(huì)產(chǎn)生應(yīng)用出現(xiàn)故障后分析困難等問題∫吃澹基于以上的背景桨嫁，企業(yè)數(shù)字化時(shí)代應(yīng)用的健康診斷變得至關(guān)重要。
問題及挑戰(zhàn)
如下圖份帐，當(dāng)代碼量的增長(zhǎng)達(dá)到 100 倍璃吧，故障被企業(yè) IT 部門察覺前已由用戶申報(bào)達(dá)到 80% 時(shí)，作為企業(yè)會(huì)非常被動(dòng)弥鹦。用戶對(duì)服務(wù)超時(shí)非常敏感肚逸，當(dāng) 5 秒打不開應(yīng)用時(shí)便會(huì)直接選擇放棄。同時(shí)彬坏，用戶對(duì)故障解決時(shí)效要求也比較高朦促，75% 的用戶希望在 5 分鐘內(nèi)解決業(yè)務(wù)故障，而業(yè)務(wù)系統(tǒng)需要超過 24 小時(shí)才能解決的故障占比在 25% 左右栓始。
應(yīng)用是一個(gè)端到端的多技術(shù)棧復(fù)雜整合環(huán)境务冕，用戶端包括移動(dòng)端、瀏覽器幻赚、小程序禀忆，網(wǎng)絡(luò)層包括路由器臊旭、防火墻和負(fù)載均衡等，后臺(tái)支撐應(yīng)用包括中間件箩退、數(shù)據(jù)庫(kù)离熏、主機(jī)、MQ 等戴涝。所以如何去高效精細(xì)化的實(shí)現(xiàn)整個(gè)應(yīng)用端到端的全鏈路性能問題洞察和診斷滋戳、快速找到故障的邊界、以及特別是 VIP 用戶出現(xiàn)性能問題如何快速追蹤啥刻。這些應(yīng)用的復(fù)雜度是企業(yè)運(yùn)維部門和業(yè)務(wù)部門都需要考慮的問題奸鸯。
傳統(tǒng)的監(jiān)控工具早已無法滿足當(dāng)前企業(yè)面臨的問題。因?yàn)橐粋€(gè)應(yīng)用會(huì)涉及到數(shù)據(jù)庫(kù)可帽、第三方的 API 調(diào)用娄涩、應(yīng)用服務(wù)器、中間件映跟、Web蓄拣、網(wǎng)絡(luò)層等多個(gè)鏈路，因此申窘，當(dāng)系統(tǒng)慢是無法快速定位就是是拿個(gè)環(huán)節(jié)弯蚜、組件以及指標(biāo)導(dǎo)致。日常企業(yè)去判斷上述問題時(shí)剃法，會(huì)需要網(wǎng)絡(luò)團(tuán)隊(duì)、開發(fā)團(tuán)隊(duì)路鹰、數(shù)據(jù)庫(kù)團(tuán)隊(duì)贷洲、基礎(chǔ)設(shè)施團(tuán)隊(duì)等多方協(xié)助排查，且排查效率較低晋柱。
