被產(chǎn)品經(jīng)理懟了，線上出Bug為啥你不知道
前言
前幾天跟讀者聊天，他說被產(chǎn)品經(jīng)理給懟了。原因是線上出 Bug 了，最后是客戶反饋才知道的。
我就問他：你們是不是沒做監(jiān)控？
讀者：我們是剛成立的創(chuàng)業(yè)團(tuán)隊(duì)，目前最重要的就是堆功能，很多基礎(chǔ)設(shè)施都沒時(shí)間做。
正所謂有多大的碗吃多少的飯，不要盲目追求規(guī)模大，很牛的那種方案，合適的就可以。監(jiān)控亦是如此，小方案只要夠用，能解決問題，也是非常不錯(cuò)的選擇。
下面給大家介紹一些常用的異常監(jiān)控方式：
最小成本化
如果是剛成立的創(chuàng)業(yè)團(tuán)隊(duì)，可以用最小的實(shí)現(xiàn)成本來對系統(tǒng)的異常進(jìn)行實(shí)時(shí)監(jiān)控。所謂最小的實(shí)現(xiàn)成本，就是可以不用依賴任何三方的框架就可以實(shí)現(xiàn)。
可以采用手動(dòng)埋點(diǎn)的方式將異常進(jìn)行告警，這種方式最好是在全局異常處理的地方進(jìn)行告警，才能統(tǒng)一管理。
如代碼所示：
@ExceptionHandler(value = Exception.class)
@ResponseBody
public ResponseData
當(dāng)我們的項(xiàng)目中有了全局異常處理，當(dāng)?shù)讓訄?bào)錯(cuò)的時(shí)候，異常都會(huì)進(jìn)入到 ExceptionHandler 進(jìn)行處理，在 ExceptionHandler 中我們可以通過 HttpServletRequest 來獲取響應(yīng)的請求信息和異常信息，然后進(jìn)行告警。
異常告警信息
異常告警信息一定要詳細(xì)，當(dāng)線上出現(xiàn)異常后，第一時(shí)間要去修復(fù)這個(gè)問題。如果沒有詳細(xì)的信息根本就無法復(fù)現(xiàn)這個(gè)問題，就不好去定位和解決了。
告警信息需要有下面的內(nèi)容：
告警服務(wù)：mobile-gateway
負(fù)責(zé)人：yinjihuan
請求地址：http://xxx.com/xxx/xxx?id=xxx
請求體：{ "name": "xxx" }
請求頭：key=value
異常碼：500
異常類型：RuntimeException
異常堆棧：java.lang.RuntimeException: com.xxx.exception.ApplicationException: 獲取XXX信息失敗！
最重要的就是請求參數(shù)了，有了參數(shù)才能復(fù)現(xiàn)錯(cuò)誤。需要注意的是通過 HttpServletRequest 獲取請求體的時(shí)候會(huì)報(bào)錯(cuò)，因?yàn)榱髦荒茏x取一次。
等到了全局異常處理類的時(shí)候已經(jīng)被讀取過了，所以我們需要特殊處理一下，寫個(gè)過濾器將請求體的值緩存起來，可以 org.springframework.web.util.ContentCachingRequestWrapper 對 HttpServletRequest 進(jìn)行裝飾，然后通過 ContentCachingRequestWrapper 獲取請求體。
最小成本化+兼顧性能
手動(dòng)埋點(diǎn)的方式對異常進(jìn)行實(shí)時(shí)告警，然后直接發(fā)送短信等告警信息，這個(gè)過程是同步的，或多或少會(huì)加大響應(yīng)的時(shí)間，不過請求進(jìn)入到異常處理這里的話就證明這個(gè)請求已經(jīng)失敗了，影響不大。
雖然影響不大，但還是可以稍微優(yōu)化一下。最常見的優(yōu)化方式就是將同步轉(zhuǎn)成異步操作，比如丟到單獨(dú)的線程池中進(jìn)行告警，丟到內(nèi)存隊(duì)列中，單獨(dú)用一個(gè)線程去獲取進(jìn)行告警。
本地異步可能出現(xiàn)丟失的情況，對于這類監(jiān)控的信息丟失幾條問題也不大，如果不想丟失，可以使用外部的消息隊(duì)列來存儲(chǔ)告警信息，有單獨(dú)的消費(fèi)者進(jìn)行消費(fèi)，告警操作。
統(tǒng)一日志監(jiān)控
最小化成本的方式，只需要稍微寫幾十行代碼就可以搞定。不好的點(diǎn)在于每個(gè)項(xiàng)目中都要有這樣一份代碼，告警的邏輯也是耦合在了代碼中。。
什么 EFK，ELK 相信大家都聽過，將日志統(tǒng)一進(jìn)行收集，集中管理。每個(gè)系統(tǒng)中在出錯(cuò)的時(shí)候需要往本地日志中寫入異常信息即可，不需要單獨(dú)對異常進(jìn)行告警，告警的動(dòng)作可以由單獨(dú)的告警系統(tǒng)來做，告警系統(tǒng)根據(jù)收集過來的日志進(jìn)行判斷，是否需要告警，告警頻次等。
統(tǒng)一日志監(jiān)控需要搭建日志平臺(tái)，成本相對來說高一點(diǎn)。當(dāng)然也可以用開源的方案，也有商業(yè)的方案。
商業(yè)的可以用云服務(wù)，使用簡單，快速接入，支持各種維度的告警規(guī)則，就是有點(diǎn)費(fèi)錢。
如果只是想對異常進(jìn)行監(jiān)控，我推薦一款開源的錯(cuò)誤追蹤系統(tǒng)，Sentry 是一個(gè)開源的實(shí)時(shí)錯(cuò)誤追蹤系統(tǒng)，可以幫助開發(fā)者實(shí)時(shí)監(jiān)控并修復(fù)異常問題，當(dāng)然 Sentry 也有商業(yè)版。
APM 監(jiān)控
apm(Application Performance Management) 除了對服務(wù)的調(diào)用鏈，性能進(jìn)行詳情的監(jiān)控，同時(shí)對異常信息也有較好的監(jiān)控。
常見的 apm 有 skywalking，pinpoint，cat 等，以 cat 來舉例，problem 報(bào)表中展示的就是應(yīng)用的錯(cuò)誤信息，而且在 cat 的首頁大盤中會(huì)按分鐘展示各個(gè)應(yīng)用的錯(cuò)誤情況，如果有大量錯(cuò)誤，大盤的顏色的就是紅色，當(dāng)你看到一片飄紅的時(shí)候，那就是異常太多了。
當(dāng)然 cat 也具備告警功能，靠人為的定時(shí)去看大盤不現(xiàn)實(shí)，當(dāng)有錯(cuò)誤后，及時(shí)的告警才有意義。想要詳細(xì)了解 cat 的可以看下我這篇文章：https://mp.weixin.qq.com/s/3mqmySr2nv4Xpd6nZlfsVg
總結(jié)
做一個(gè)最小成本化的異常監(jiān)控，估計(jì)也就一天搞定了。如果你不做，那就只能等著被懟啦。要控制不出 bug 幾乎不可能，是程序就肯定會(huì)有 bug。我們需要做的就是在出 bug 的第一時(shí)間內(nèi)及時(shí)發(fā)現(xiàn)這個(gè) bug，然后消滅它。