前言

在系統(tǒng)上線之后，或多或少總是會存在問題，有機器性能方面的問題，例如CPU Load過高，內(nèi)存使用率高，RT高，線程池滿，F(xiàn)ullGC之類，也有業(yè)務(wù)邏輯的問題，例如支付系統(tǒng)中金額計算錯誤，狀態(tài)校驗錯誤等。為了盡量減少線上的影響（對用戶造成困擾，甚至導(dǎo)致資金損失等），對系統(tǒng)的穩(wěn)定性監(jiān)控建設(shè)還是很有必要的。

從方法論的角度來看，很多事情都可以歸納為信息收集能力，信息的處理能力。穩(wěn)定性也類似，需要多維的收集信息，然后根據(jù)信息發(fā)現(xiàn)系統(tǒng)的運行狀態(tài)。

數(shù)據(jù)收集

不過方法論如果抽象層次過高，就變得不易落地的，因此還需要結(jié)合具體的場景細化，目標(biāo)是信息維度足夠詳細，可以有效的輔助問題的分析。結(jié)合穩(wěn)定性場景的話，分為系統(tǒng)與業(yè)務(wù)兩部分?jǐn)?shù)據(jù)。系統(tǒng)方面數(shù)據(jù)比較通用，通常包括機器的CPU情況（CPU使用率，LOAD等情況），內(nèi)存使用率（JVM內(nèi)存情況，GC的情況），磁盤使用率，網(wǎng)絡(luò)的流量情況，以及分布式中一些中間件的情況，例如服務(wù)的RT，線程池使用情況，緩存的RT，命中率，消息的堆積情況，任務(wù)調(diào)動的執(zhí)行情況等等，以及數(shù)據(jù)庫的執(zhí)行情況，例如慢sql等等。如果存在不同的機房還需要把機房情況也列出來，例如安全生產(chǎn)環(huán)境，正式環(huán)境，不同的機房，不同的單元等，這樣可以有效定位到影響面。業(yè)務(wù)數(shù)據(jù)主要是需要根據(jù)具體業(yè)務(wù)進行分析，梳理出業(yè)務(wù)關(guān)注的指標(biāo)，不過通用的一般有入口情況（可以分不同的場景，例如PC端，無線端，小程序端等，總量，成功率），依賴情況（依賴服務(wù)的成功率， RT等，總量），系統(tǒng)的錯誤碼情況（統(tǒng)一錯誤碼），同樣也需要分不同的機房情況。其他具體業(yè)務(wù)指標(biāo)就需要結(jié)合業(yè)務(wù)具體分析了，例如支付系統(tǒng)中，每個支付渠道的提交成功率，支付成功率，耗時等。對于業(yè)務(wù)指標(biāo)可以根據(jù)線上真實出現(xiàn)過的問題或者自己假想出現(xiàn)一類問題，自己需要哪些信息來慢慢完善。 對于單一的應(yīng)用系統(tǒng)通?？梢员容^有效的進行監(jiān)控與巡檢，如果是全鏈路的系統(tǒng)，就需要對鏈路上的系統(tǒng)分別建設(shè)，不過業(yè)務(wù)上的監(jiān)控一般可以跨越多系統(tǒng)。

數(shù)據(jù)處理

數(shù)據(jù)收集好之后，另外需要了解數(shù)據(jù)背后的意義，這里就是基礎(chǔ)知識以及經(jīng)驗的積累。例如當(dāng)發(fā)現(xiàn)系統(tǒng)提供的服務(wù)RT上升時，應(yīng)該如何排查。當(dāng)支付寶渠道的支付成功數(shù)下降應(yīng)該如何排查。這些也都可以通過問題處理的經(jīng)驗梳理處理。

服務(wù)RT上升

1. 排查依賴的系統(tǒng)RT是否上升，如何下游系統(tǒng)都是自己域內(nèi)，那就以此排查，如果不是域內(nèi)，就需要聯(lián)系對應(yīng)的owner進行排查

2. 如果依賴的服務(wù)RT沒有上升，看是否請求量是否明顯上漲，導(dǎo)致機器負(fù)載過高

3. 是否應(yīng)用機器是否剛剛啟動，由于jvm對代碼進行編譯導(dǎo)致時間過長；

4. 查看CPU使用率，Load，內(nèi)存使用率，GC的次數(shù)，GC耗時，線程數(shù)大小，JVM堆內(nèi)存使用情況

5. 如果是虛擬機，還需要查看宿主機的情況

支付成功數(shù)下跌

1. 入口是否有下跌

2. 各渠道成功數(shù)是否下跌

3. 對應(yīng)的渠道收銀臺與支付的報錯

4. 對應(yīng)的成功回調(diào)，從外層到內(nèi)層依次排查

其他

監(jiān)控一方面可以提升問題排查的速度，也可以對于問題進行告警，避免問題的放大。