聊聊監控那點事：自主研發，基於日誌分析的監控系統

遇到假期，一般都是體重飆升的好日子，國慶如此，元旦如此，春節更是有過之而無不及啦...今年春節與以往不同，在長假中靠著『人肉化提醒(老婆嘮叨)』與『自動化提醒(手機軟體)』，每天堅持運動+控制cal射入，體重和體脂都有不同的下降

言歸真轉，前面這段話不但是為了暖場，也有引入正題的作用，我記得當時在東方購物開發時(2004-2006)，常把系統與人體進行比較，用於說明系統的複雜度，比如當人鬧肚子或者頭痛腦熱時，第一想到的當然是去醫院進行檢查，由醫生通過自己的經驗或是醫療儀器給出診斷結果，要麼打針，要麼吃藥，或者直接開出個『病危通知書』了事......

人不舒服了可以去醫院，那系統『不舒服』該怎麼辦呢？

等一下，比如某一個應用系統表示『不舒服』，會有哪些的表現形式呢？比如服務無法響應、服務請求返回失敗、服務響應慢等（不一一列舉了）

當異常或錯誤發生時，快速發現、定位、解決就變得尤其重要，相信很多同學都有過「出現問題，老闆站在你背後看著你解決問題」的慘痛經歷，而且還會問你「為什麼我們不能早於客戶發現問題呢？」

分久必合，合久必分

以微服務作為系統發展方向，去中心化變得很重要，但在很多系統的發展史中，基本路徑都是「從系統孤島 ——> 大一統或一大坨 ——> 子系統系統拆分 ——> 微服務」

很難找到一套解決方案，伴隨著這樣一個路徑成長或演化（本來監控就不是研發重視的視角），雖然DevOPS理念滿天飛，而且方式也顯得非常合體，但執行中，不是人的問題，就是這樣那樣的問題，很難短期達到效果

為什麼要建這套監控平台，我們現狀痛點是什麼？

• to 運維

• 系統往分散式系統的方向發展、系統和系統的依賴難以知曉
• 故障排查成本高
• 系統的壓力和系統的水位分析
• to 測試

• 壓力分布測試難
• to 開發

• 系統排查錯誤成本高

這套監控平台，能為我們提供什麼呢？

• 一張清晰的系統概況&網路拓撲

系統介面的依賴關係

• 針對請求的調用鏈關係

這套監控平台，我們如何實現他呢？

• 應用埋點

• 應用需按照要求輸出日誌

未完待續，繼續前進

如果算上從設想到現在，應該已經有了2個年頭，目前這套系統已應用在公司的各個業務線中，也起到了或多或少的作用，隨著系統的拆分或微服務化得推進，應該還能有不少的改進、突破，拭目以待吧~

推薦閱讀：