原創：猿天地（微信公衆號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微服務 入門 實戰與進階》作者, 公衆號猿天地發起人。