被產品經理懟了，線上出Bug為啥你不知道

前言

前幾天跟讀者聊天，他說被產品經理給懟了。原因是線上出 Bug 了，最後是客戶反饋才知道的。

我就問他：你們是不是沒做監控？

讀者：我們是剛成立的創業團隊，目前最重要的就是堆功能，很多基礎設施都沒時間做。

正所謂有多大的碗吃多少的飯，不要盲目追求規模大，很牛的那種方案，合適的就可以。監控亦是如此，小方案只要夠用，能解決問題，也是非常不錯的選擇。

下面給大家介紹一些常用的異常監控方式：

最小成本化

如果是剛成立的創業團隊，可以用最小的實現成本來對系統的異常進行實時監控。所謂最小的實現成本，就是可以不用依賴任何三方的框架就可以實現。

可以採用手動埋點的方式將異常進行告警，這種方式最好是在全局異常處理的地方進行告警，才能統一管理。

如程式碼所示：

@ExceptionHandler(value = Exception.class)
@ResponseBody
public ResponseData<Object> defaultErrorHandler(HttpServletRequest req, Exception e) {
   // 記錄異常
   // 釘釘或者簡訊告警
}

當我們的項目中有了全局異常處理，當底層報錯的時候，異常都會進入到 ExceptionHandler 進行處理，在 ExceptionHandler 中我們可以通過 HttpServletRequest 來獲取響應的請求資訊和異常資訊，然後進行告警。

異常告警資訊

異常告警資訊一定要詳細，當線上出現異常後，第一時間要去修復這個問題。如果沒有詳細的資訊根本就無法復現這個問題，就不好去定位和解決了。

告警資訊需要有下面的內容：

告警服務：mobile-gateway
負責人：yinjihuan
請求地址：http://xxx.com/xxx/xxx?id=xxx
請求體：{ "name": "xxx" }
請求頭：key=value
異常碼：500
異常類型：RuntimeException
異常堆棧：java.lang.RuntimeException: com.xxx.exception.ApplicationException: 獲取XXX資訊失敗！

最重要的就是請求參數了，有了參數才能復現錯誤。需要注意的是通過 HttpServletRequest 獲取請求體的時候會報錯，因為流只能讀取一次。

等到了全局異常處理類的時候已經被讀取過了，所以我們需要特殊處理一下，寫個過濾器將請求體的值快取起來，可以 org.springframework.web.util.ContentCachingRequestWrapper 對 HttpServletRequest 進行裝飾，然後通過 ContentCachingRequestWrapper 獲取請求體。

最小成本化+兼顧效能

手動埋點的方式對異常進行實時告警，然後直接傳送簡訊等告警資訊，這個過程是同步的，或多或少會加大響應的時間，不過請求進入到異常處理這裡的話就證明這個請求已經失敗了，影響不大。

雖然影響不大，但還是可以稍微優化一下。最常見的優化方式就是將同步轉成非同步操作，比如丟到單獨的執行緒池中進行告警，丟到記憶體佇列中，單獨用一個執行緒去獲取進行告警。

本地非同步可能出現丟失的情況，對於這類監控的資訊丟失幾條問題也不大，如果不想丟失，可以使用外部的訊息佇列來儲存告警資訊，有單獨的消費者進行消費，告警操作。

統一日誌監控

最小化成本的方式，只需要稍微寫幾十行程式碼就可以搞定。不好的點在於每個項目中都要有這樣一份程式碼，告警的邏輯也是耦合在了程式碼中。。

什麼 EFK，ELK 相信大家都聽過，將日誌統一進行收集，集中管理。每個系統中在出錯的時候需要往本地日誌中寫入異常資訊即可，不需要單獨對異常進行告警，告警的動作可以由單獨的告警系統來做，告警系統根據收集過來的日誌進行判斷，是否需要告警，告警頻次等。

統一日誌監控需要搭建日誌平臺，成本相對來說高一點。當然也可以用開源的方案，也有商業的方案。

商業的可以用雲服務，使用簡單，快速接入，支援各種維度的告警規則，就是有點費錢。

如果只是想對異常進行監控，我推薦一款開源的錯誤追蹤系統，Sentry 是一個開源的實時錯誤追蹤系統，可以幫助開發者實時監控並修復異常問題，當然 Sentry 也有商業版。

APM 監控

apm(Application Performance Management) 除了對服務的呼叫鏈，效能進行詳情的監控，同時對異常資訊也有較好的監控。

常見的 apm 有 skywalking，pinpoint，cat 等，以 cat 來舉例，problem 報表中展示的就是應用的錯誤資訊，而且在 cat 的首頁大盤中會按分鐘展示各個應用的錯誤情況，如果有大量錯誤，大盤的顏色的就是紅色，當你看到一片飄紅的時候，那就是異常太多了。

當然 cat 也具備告警功能，靠人為的定時去看大盤不現實，當有錯誤後，及時的告警才有意義。想要詳細瞭解 cat 的可以看下我這篇文章：https://mp.weixin.qq.com/s/3mqmySr2nv4Xpd6nZlfsVg

總結

做一個最小成本化的異常監控，估計也就一天搞定了。如果你不做，那就只能等著被懟啦。要控制不出 bug 幾乎不可能，是程式就肯定會有 bug。我們需要做的就是在出 bug 的第一時間內及時發現這個 bug，然後消滅它。

碼字不易，可以的話來個三連擊，感謝！

關於作者： 尹吉歡，簡單的技術愛好者，《Spring Cloud微服務-全棧技術與案例解析》, 《Spring Cloud微服務 入門 實戰與進階》作者, 公眾號 猿天地 發起人。

我整理了一份很全的學習資料，感興趣的可以微信搜尋 「猿天地 」，回覆關鍵字 「學習資料 」獲取我整理好了的Spring Cloud，Spring Cloud Alibaba，Sharding-JDBC分庫分表，任務排程框架XXL-JOB，MongoDB，爬蟲等相關資料。