原創:猿天地(微信公眾號ID:cxytiandi),歡迎分享,轉載請保留出處。
監控這個話題永遠都不會過時,之前也有跟大家聊過監控的內容,以及如何快速實現監控滿足日常需求。比如基於日誌告警,基於全域性異常處理器告警,基於Cat,Prometheus,Sentry等告警。
無論公司是什麼規模,創業小公司,穩定大公司,你都需要做監控的呀。特別是大公司的監控做的更全,也更在意監控這件事情。小公司相對來說會好點,因為業務可能還不是很穩定,使用者少,出故障就出唄,能修復就行。
監控的痛點
有監控總比沒監控要強吧,但是監控多了也不見得是件好事。此處的監控多了有兩層含義。
含義一:監控體系多或者說監控的框架多
很多時候,公司裡的監控五花八門,有Sentry做異常告警,又有日誌異常告警。有Cat又有SkyWalking,弄的你懷疑人生,到底用哪個,異常資訊各種重複。
唯一的好處就是一有問題,你就慌的不行,怎麼這麼多異常告警。馬上去排查問題了,導致自驅力非常好。
含義二:監控告警量多
監控框架多了,告警的數量自然是翻倍的,這點毋庸置疑。其實更為重要的一點是告警沒有做等級劃分,一頓亂報,導致告警群裡一直有告警資訊。有點像狼來了的意思,後面你就懶得去看了,因為太多了。
如何解決痛點
監控體系統一
首先,監控體系要進行整理,採用統一的監控框架。a但很多時候往往某一個框架無法滿足所有需求,這種場景下就出現了混合使用,控制的不好就跟前面提的一樣,五花八門了。
在某一個監控層面能夠覆蓋大部分的場景即可。如果不行,可能需要基於已有的開源監控體系進行自研擴充套件功能了。
告警定級
監控體系統一後,最大的問題就是異常的告警。是否所有的異常需要告警?告警能不能分類定級?
異常分為兩種,執行時異常,比如NPE之類的。另一種非常多的就是業務異常,比如庫存不足,商品已下架等。
對於執行時異常,一定是第一優先順序,因為這就是Bug,需要馬上關注並且處理。這類異常往往不會很多,如果非常多,那就是你的程式碼真的寫的不咋的。
告警分類細化
對於業務異常,告警級別可以下降。這類異常雖然不能反饋系統有問題,但是能反饋業務的狀態,還是需要稍微關注下。比如電商中最核心的下單介面,1分鐘內下單失敗100次,這種情況能不關注嗎?必須得關注。
業務異常除了降級之外還得分類,這個就需要在丟擲業務異常的時候宣告對應的code碼才行。這樣在告警的時候直接帶上對應的code碼,一看便知什麼問題。比如前面將的下單頻繁失敗,如果你只是告警說下單失敗了多少,那麼此時你一定很慌,因為你壓根就不知道為什麼?
還得屁顛屁顛的去看日誌之類的,排查報錯的真正原因。如果告警時就已經帶上了code碼 1001,你一看就知道,庫存不足了,肯定是某個商品在搶購。code碼1002風控校驗超時了,馬上聯絡風控的同學進行排查。這樣的告警才符合標準,否則太累了。
最重要的是保留好現場資料,也就是出參和響應以及traceId,否則談何去解決這個告警問題。
總結
改造完後,只有執行時異常或者某分鐘內大量報錯才會簡訊或者電話緊急告警,減少騷擾。其他業務異常等直接走釘釘啊,飛書啊這種告警群即可。告警群也可以細化,劃分為需要關注的code和不需要關注的code, 分開不同的群,提高資訊的精準度觸達和消費。
本文主要講的還是專案內的異常告警,其他的像一些中介軟體啊,資料庫之類的告警就不用這麼分了,這些一旦告警,無論是cpu飆高還是記憶體飆高都是很嚴重的問題,都需要關注以及做預案處理。
關於作者:尹吉歡,簡單的技術愛好者,《Spring Cloud微服務-全棧技術與案例解析》, 《Spring Cloud微服務 入門 實戰與進階》作者, 公眾號猿天地發起人。