作者簡(jiǎn)介：
黃小龍 (易寶支付CTO)
摘要：
隨著業(yè)務(wù)系統(tǒng)的不斷迭代建設(shè)，基于現(xiàn)有的日志監(jiān)控系統(tǒng)或報(bào)警平臺(tái)，是否能夠精準(zhǔn)的定位問(wèn)題根源及自動(dòng)化實(shí)時(shí)捕捉微小的異常或錯(cuò)誤在系統(tǒng)運(yùn)行的過(guò)程中會(huì)有什么樣的影響?面向業(yè)務(wù)提供全棧性能監(jiān)控和分析的訴求凸顯越來(lái)越重要，本文將結(jié)合應(yīng)用監(jiān)控架構(gòu)設(shè)計(jì)的最佳實(shí)踐原則(《架構(gòu)即未來(lái)》第三十一章節(jié)“應(yīng)用監(jiān)控”)，結(jié)合實(shí)際的監(jiān)控架構(gòu)設(shè)計(jì)的思路，引申出應(yīng)用性能監(jiān)控建設(shè)架構(gòu)并結(jié)合實(shí)際案例加以介紹。
“系統(tǒng)事故對(duì)企業(yè)的損失不言而喻，與其投入重點(diǎn)精力做時(shí)候的補(bǔ)救，倒不如提前在之前做好架構(gòu)設(shè)計(jì)和業(yè)務(wù)應(yīng)用監(jiān)控。” ——摘自《架構(gòu)即未來(lái)》之應(yīng)用架構(gòu)核心思想
監(jiān)控架構(gòu)的核心思想
當(dāng)企業(yè)處在快速成長(zhǎng)的時(shí)期，業(yè)務(wù)系統(tǒng)也在不斷的迭代更新中，如若無(wú)法快速識(shí)別系統(tǒng)可擴(kuò)展的瓶頸，必將遭受長(zhǎng)期的系統(tǒng)服務(wù)中斷的痛苦，因?yàn)槿魏挝⑿〉漠惓ｋ[患或程序報(bào)錯(cuò)的發(fā)生，輕則影響用戶體驗(yàn)，造成用戶埋怨不斷，重則可能會(huì)引發(fā)系統(tǒng)的故障，如業(yè)務(wù)系統(tǒng)宕機(jī)這般災(zāi)難性的故障。在參與過(guò)往的業(yè)務(wù)系統(tǒng)應(yīng)急處理過(guò)程中，經(jīng)事后RCA(Root Cause Analyze )的源頭分析發(fā)現(xiàn)均有共同點(diǎn)，就是引發(fā)錯(cuò)誤的根源被隱藏極深，在事故處理過(guò)程中很難短時(shí)間內(nèi)發(fā)現(xiàn)源頭的端倪，即便通過(guò)了嚴(yán)格的業(yè)務(wù)變更評(píng)審及DBA細(xì)致的SQL走查，終究會(huì)有一些“漏網(wǎng)之魚(yú)”，而這些問(wèn)題通常在標(biāo)準(zhǔn)的業(yè)務(wù)覆蓋回歸測(cè)試中很難被發(fā)現(xiàn)，也只有在生產(chǎn)運(yùn)行后的一段時(shí)間，被某種“神奇的力量”觸發(fā)。要想做到事前預(yù)防或在最佳時(shí)期處理清楚問(wèn)題隱患，確保業(yè)務(wù)大規(guī)模上量后能夠穩(wěn)健的運(yùn)行，則需要思考的問(wèn)題是 “基于現(xiàn)有的日志監(jiān)控系統(tǒng)或報(bào)警平臺(tái)，是否能夠精準(zhǔn)的定位問(wèn)題根源及自動(dòng)化實(shí)時(shí)捕捉微小的異?；蝈e(cuò)誤在系統(tǒng)運(yùn)行的過(guò)程中會(huì)有什么樣的影響?”
如果想要能精準(zhǔn)定位并具備相應(yīng)的能力來(lái)捕獲這些“漏網(wǎng)之魚(yú)”，便離不開(kāi)應(yīng)用監(jiān)控架構(gòu)的思路來(lái)指導(dǎo)。因?yàn)橐瓿蛇@件事情，有過(guò)行業(yè)經(jīng)驗(yàn)的朋友或?qū)＜視?huì)告訴你，這不僅僅需要有大量的信息來(lái)搜集和檢索，如統(tǒng)一的大數(shù)據(jù)日志監(jiān)控系統(tǒng)(ELK)，還得要有非常得力的應(yīng)用性能管理(Application Performance Management)工具如云智慧透視寶進(jìn)行7*24小時(shí)實(shí)時(shí)的監(jiān)測(cè)分析，一旦出現(xiàn)問(wèn)題可以做到秒級(jí)甚至毫秒級(jí)別的快速捕捉問(wèn)題，通過(guò)配套的自動(dòng)檢查分析機(jī)制，來(lái)篩選并驗(yàn)證一些細(xì)小的錯(cuò)誤，在通過(guò)共性部分來(lái)反查應(yīng)用代碼，刨根問(wèn)底，發(fā)現(xiàn)存在的隱患是不是引發(fā)災(zāi)難源頭。比如發(fā)生了故障，首先會(huì)考慮的是“出問(wèn)題了嗎?”之后就是“出什么問(wèn)題了?”然后就是“問(wèn)題出在哪里?”最后便是“是什么問(wèn)題?”隨著問(wèn)題的遞進(jìn)和深入，所需要回答和準(zhǔn)備的數(shù)據(jù)也越來(lái)越多，這也是數(shù)據(jù)規(guī)模與問(wèn)題針對(duì)性之間的重要聯(lián)系(見(jiàn)下圖)，作為架構(gòu)設(shè)計(jì)者和事故處理負(fù)責(zé)人必然會(huì)問(wèn)到的這四個(gè)核心問(wèn)題。
圖一：數(shù)據(jù)規(guī)模與問(wèn)題針對(duì)性之間的關(guān)系，摘自 “《架構(gòu)即未來(lái)》第三十一章 應(yīng)用監(jiān)控架構(gòu)P31.3”
應(yīng)用監(jiān)控架構(gòu)的核心思想就是幫助運(yùn)維改變這樣的窘迫局面：“每次發(fā)生系統(tǒng)級(jí)別故障，花費(fèi)很長(zhǎng)的時(shí)間去定位引發(fā)故障的根源如變更的步驟遺落、代碼編寫不規(guī)范、業(yè)務(wù)SQL的超出標(biāo)準(zhǔn)等，這些根源所引發(fā)的問(wèn)題都不一樣，都需要經(jīng)過(guò)各式各樣的應(yīng)急去處理，直到事后的問(wèn)題整改，完成故障的閉環(huán)。看似標(biāo)準(zhǔn)符合邏輯，但這樣周而復(fù)始下去，往輕的一方面解讀是在業(yè)務(wù)上所反饋出來(lái)表象便是讓商戶或用戶不斷的試錯(cuò)，正常的業(yè)務(wù)交易中斷，逐漸地喪失了對(duì)產(chǎn)品的信心;往重的方面去分析，業(yè)務(wù)系統(tǒng)的故障，會(huì)增加企業(yè)的運(yùn)營(yíng)成本，甚至影響核心的技術(shù)團(tuán)隊(duì)實(shí)力”我們不妨換個(gè)思路來(lái)，首先解決“問(wèn)題發(fā)生之前有盡早發(fā)現(xiàn)故障前兆的報(bào)錯(cuò)或者異常信息?”，因此，引申出了我們?cè)谶M(jìn)行業(yè)務(wù)應(yīng)用監(jiān)控架構(gòu)設(shè)計(jì)的核心思想，這也是為客戶提供更好的服務(wù)水平承諾(SLA：Service Level Agreement)的標(biāo)準(zhǔn)化結(jié)構(gòu)設(shè)計(jì)重點(diǎn)。為提升用戶體驗(yàn)，系統(tǒng)的平均響應(yīng)時(shí)間(ART：Average Response Time)和有效成功率(EST：Effective Success Rate)這兩大指標(biāo)也是面向應(yīng)用監(jiān)控可量化衡量的參考依據(jù)。