點擊上方藍色字體，選擇“設為星標”

監(jiān)控這個話題永遠都不會過時，之前也有跟大家聊過監(jiān)控的內(nèi)容，以及如何快速實現(xiàn)監(jiān)控滿足日常需求。比如基于日志告警，基于全局異常處理器告警，基于 Cat，Prometheus，Sentry 等告警。

無論公司是什么規(guī)模，創(chuàng)業(yè)小公司，穩(wěn)定大公司，你都需要做監(jiān)控的呀。特別是大公司的監(jiān)控做的更全，也更在意監(jiān)控這件事情。小公司相對來說會好點，因為業(yè)務可能還不是很穩(wěn)定，用戶少，出故障就出唄，能修復就行。

監(jiān)控的痛點

有監(jiān)控總比沒監(jiān)控要強吧，但是監(jiān)控多了也不見得是件好事。此處的監(jiān)控多了有兩層含義。

含義一：監(jiān)控體系多或者說監(jiān)控的框架多

很多時候，公司里的監(jiān)控五花八門，有 Sentry 做異常告警，又有日志異常告警。有 Cat 又有 SkyWalking，弄的你懷疑人生，到底用哪個，異常信息各種重復。

唯一的好處就是一有問題，你就慌的不行，怎么這么多異常告警。馬上去排查問題了，導致自驅(qū)力非常好。

含義二：監(jiān)控告警量多

監(jiān)控框架多了，告警的數(shù)量自然是翻倍的，這點毋庸置疑。其實更為重要的一點是告警沒有做等級劃分，一頓亂報，導致告警群里一直有告警信息。有點像狼來了的意思，后面你就懶得去看了，因為太多了。

如何解決痛點

監(jiān)控體系統(tǒng)一

首先，監(jiān)控體系要進行整理，采用統(tǒng)一的監(jiān)控框架。a 但很多時候往往某一個框架無法滿足所有需求，這種場景下就出現(xiàn)了混合使用，控制的不好就跟前面提的一樣，五花八門了。

在某一個監(jiān)控層面能夠覆蓋大部分的場景即可。如果不行，可能需要基于已有的開源監(jiān)控體系進行自研擴展功能了。

告警定級

監(jiān)控體系統(tǒng)一后，最大的問題就是異常的告警。是否所有的異常需要告警？告警能不能分類定級？

異常分為兩種，運行時異常，比如 NPE 之類的。另一種非常多的就是業(yè)務異常，比如庫存不足，商品已下架等。

對于運行時異常，一定是第一優(yōu)先級，因為這就是 Bug，需要馬上關(guān)注并且處理。這類異常往往不會很多，如果非常多，那就是你的代碼真的寫的不咋的。

告警分類細化

對于業(yè)務異常，告警級別可以下降。這類異常雖然不能反饋系統(tǒng)有問題，但是能反饋業(yè)務的狀態(tài)，還是需要稍微關(guān)注下。比如電商中最核心的下單接口，1 分鐘內(nèi)下單失敗 100 次，這種情況能不關(guān)注嗎？必須得關(guān)注。

業(yè)務異常除了降級之外還得分類，這個就需要在拋出業(yè)務異常的時候聲明對應的 code 碼才行。這樣在告警的時候直接帶上對應的 code 碼，一看便知什么問題。比如前面將的下單頻繁失敗，如果你只是告警說下單失敗了多少，那么此時你一定很慌，因為你壓根就不知道為什么？

還得屁顛屁顛的去看日志之類的，排查報錯的真正原因。如果告警時就已經(jīng)帶上了 code 碼 1001，你一看就知道，庫存不足了，肯定是某個商品在搶購。code 碼 1002 風控校驗超時了，馬上聯(lián)系風控的同學進行排查。這樣的告警才符合標準，否則太累了。

最重要的是保留好現(xiàn)場數(shù)據(jù)，也就是出參和響應以及 traceId，否則談何去解決這個告警問題。

總結(jié)

改造完后，只有運行時異?；蛘吣撤昼妰?nèi)大量報錯才會短信或者電話緊急告警，減少騷擾。其他業(yè)務異常等直接走釘釘啊，飛書啊這種告警群即可。告警群也可以細化，劃分為需要關(guān)注的 code 和不需要關(guān)注的 code, 分開不同的群，提高信息的精準度觸達和消費。

本文主要講的還是項目內(nèi)的異常告警，其他的像一些中間件啊，數(shù)據(jù)庫之類的告警就不用這么分了，這些一旦告警，無論是 cpu 飆高還是內(nèi)存飆高都是很嚴重的問題，都需要關(guān)注以及做預案處理。

歡迎關(guān)注微信公眾號：互聯(lián)網(wǎng)全棧架構(gòu)，收取更多有價值的信息。