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