文章目錄
開發中的日誌報警和數據流報警
沒有最好的，只有最合適的…
最近團隊總結會議增加了一個吐槽的環節，可以把自己平時在工作中不滿意的地方集中吐槽出來，然後收集起來，排名前三的吐槽點可以在下週計劃會議中優先討論解決。（P.S. 如果真的能夠利用好這一環節的話，對整個團隊帶來的價值還是相當可觀的）
這周我拋出的一個問題就是題目中的報警。
由於團隊一開始計劃就是採用分模塊、CI/CD 的方式開發、部署、迭代，所以整個產品被切分爲好多小模塊並且docker化，使用 k8s 管理，各個模塊之間通過 http 和 kafka 的方式串聯起來，採集數據流入、處理、保存、最終以 web 和 API 的方式輸出給用戶。
產品部署在 開發、測試、demo、生產 四個大環境。
監控報警方面呢，團隊採用的監控報警方式是以 特定輸入 和 得到預期的輸出 方式來設計開發的，忽略中間所有數據處理過程。這倒也是個簡單有效的思路。然後監控到問題會分級別以郵件、電話的形式通知給 group 中的人員。
然後問題來了：
- 郵件客戶端撐爆了。測試、demo、生產 三個環境中，不管是 數據超時、數據恢復、數據斷流、還是其它，每天成百上千封的郵件破天蓋地而來，怕不怕！一開始認真看一下報警信息，時間一久，完全成了體力活，除非每天篩選刪除郵件，不然郵箱客戶端會越來越慢，最終這種報警氾濫的方式讓我關掉了郵件客戶端，整個世界清靜了，專心開發，嚴重問題自然會有人來專門通知！
- 問題排查困難。由於設計的缺陷，並沒有考慮打印日誌信息和級別，導致排查問題異常困難。比如：數據流數據丟失問題，沒有返回數據，得到的報警信息就是某數據沒得到輸出，其中數據會經過好多數據流的小模塊，而且 有的模塊 log 信息都沒有（這個玩笑開的有點大），沒辦法第一時間定位到問題，只能硬着頭皮重新花費時間重現問題，翻閱前人源碼來認真調試查找問題（說多了都是淚）。
- 破窗原理。引發一系列其他問題。
拋出問題，沒有解決方案的碼農不是好的程序員。
首先，需要定義一套日誌規範，尤其是日誌級別、關鍵信息要明確；
然後，添加日誌和數據流監控結合的方式，可以監控數據流健康，也可以根據日誌快速定位問題，快速解決問題；
最後，報警消息對應 group 組的粒度細分，拒絕報警消息氾濫。
(僅以此獻給每一個一線研發人員)
—2019-11-30—