目前系統監控的手段比較多，大致可以分爲三類：業務監控，應用監控和系統監控。
業務監控監測業務指標，比如下單量，用戶註冊數等，從業務數據來評估當前系統是否正常。
應用監控針對具體的應用，一般從接口調用的角度檢測應用狀態，比如調用數量 / 響應時間 / 錯誤數等，有很多 APM 工具可以做到這點。
系統監控針對物理機器資源，比如 CPU/ 內存 / 磁盤使用情況等，Zabbix 是典型的工具。
這些監控針對不同維度，監控結果在不同的系統裏輸出，比較分散；而且由不同的人負責，比如運維負責 Zabbix，開發負責應用監控。在系統真正出問題的時候，從發現問題到定位問題，再到解決問題，協作困難，造成事故時間長，業務影響大。
本人基於實際的監控痛點，通過一體化地監控手段，比較高效地解決大型系統的監控問題，這裏拋磚引玉，和大家探討一下。
本文的內容包括：
1) 監控痛點
2) 解決思路
3) 架構方案
4) 監控效果
5) 總結
1. 監控痛點
大型的互聯網平臺，特別是面向 C 端的交易類系統，當線上發生問題，通常要求分鐘級的處理速度。比如美團 / 餓了嗎外賣平臺，停擺 10 分鐘，相信無數的商家 / 騎手 / 消費者會大規模投訴，這不僅是經濟損失，平臺商譽也會受嚴重影響。
這些平臺背後都是大規模的分佈式系統，有各種應用，還有基礎組件 (數據庫 / 緩存 /MQ 等)，共同組成複雜的依賴網絡，任何節點都可能出問題，導致系統不可用。這樣對系統的監控就非常重要，通過監控，及時干預，避免事故或縮短事故時間。
大型交易類平臺監控還是相對完善的，一般由很多塊屏幕組成一個屏幕牆，包括業務曲線監控（業務監控），關鍵應用的接口調用和出錯情況（應用監控），網絡和數據庫監控（系統監控），但是事故發生時，還是一大堆人手忙腳亂，無所適從。
這裏舉一個典型的線上事故處理例子：
Monitor 發現訂單曲線突然跌停，快速拉起電話會議或羣裏 @大堆的人排查。
運維檢查網絡和機器，開發檢查錯誤日誌，DBA 檢查數據庫。然後負責 APP 服務端的開發在 ELK 發現大量的調用下單服務超時，詢問下單服務怎麼回事，並給出調用例子；下單服務根據調用例子檢索錯誤日誌，發現調用會員服務大量超時，問會員服務怎麼回事；會員服務檢索錯誤日誌，發現訪問會員數據庫連接超時，問 DBA 怎麼回事；DBA 拉上網絡同事一起看，發現網絡沒問題，而是會員數據庫有慢查詢把 DB 掛住；最後 DBA 把慢查詢殺掉，系統暫時恢復正常，大家都鬆了一口氣。這個時候距離問題發生已經過去很長時間。在此期間，技術總監被 CTO 催了 N 次，CTO 被 CEO 催了 2N 次，CEO 被客戶催了 N x N 次，客戶被消費者投訴了 N x N x N 次。
可以看到，雖然有很多監控手段或者大屏監控，但真正出事故時，能發揮的用處還是比較有限，那這裏面具體有哪些問題呢？
第一發現問題慢，業務曲線一般 1 分鐘更新一次，有時候因爲正常的業務抖動，還需把這種情況確認排除掉，帶來很大的滯後性。
第二定位問題慢，系統龐大，大量的人需要介入排查，而且由於依賴複雜，需要反覆溝通才能串起來。一方面無關的人捲入進來，人員浪費，另一方面溝通效率低，定位問題時間長。
第三解決問題慢，當定位到問題，對系統進行調整後，驗證問題是否解決也不是容易的事。更新大量機器需要時間，然後需要各個研發確認系統有沒問題，還要通過滯後的業務曲線看業務是否恢復。有時病急亂投醫，往往會發生二次事故，這裏的問題是缺乏實時直觀的反饋途徑。
2. 解決思路
如何有效解決監控上的這些痛點，快速處理線上事故呢？
我們可以借鑑道路交通監控的例子，在交通監控圖上，每條道路通過上下左右方位有機地關聯在一起，形成整體的交通網絡，同時通過紅黃綠三種狀態實時反映擁堵情況。司機可以非常直觀地獲取信息，及時避開擁堵路段：
這裏有幾個關鍵詞：實時，整體，直觀。
首先要實時，馬上知道系統當前是否有問題。
然後要針對系統做整體監控，把各個部分放一起，能夠迅速識別哪些部分是好的，哪些部分不好。有問題的部分，又有可能是它依賴的部分引起的，因此依賴關係也要直觀展示，便於定位真正的問題源。
最後要直觀，發生緊急事故時，人腦處於錯亂狀態，這時候，不能借助專業的頭腦或嚴密的分析才能判斷。哪些部分有問題，問題嚴重程度，以及出問題的原因必須一目瞭然，不能連累他人。誰家的娃有問題，各找各媽，各回各家。
如果我們能按照道路交通監控的思路，對我們的系統提供類似的監控，那就非常理想，每個系統節點對應一條道路，應用的健康狀況對應道路擁堵情況，應用的上下游依賴關係對應道路的方位關係，這樣我們就能構建一個實時直觀的一體化監控體系。
回到剛纔的例子，我們的系統交通圖監控如此設計，首先聚合層應用，各種服務（下單服務，會員服務，商品服務，庫存服務，促銷服務等），各個服務對應的 Redis，MQ 和數據庫，這些節點按照相互調用關係放在一張圖裏。出上述問題時，聚合層應用 ->下單服務 ->會員服務 ->會員數據庫這 4 個節點都會爆紅，其他節點保持綠色。前 3 個節點有錯誤消息提示接口調用超時，會員數據庫節點提示數據庫連接超時。這樣首先其他節點可以不用排查，然後觀察爆紅的節點，通過直觀的上下游依賴關係，知道最終問題很可能出在會員數據庫上，DBA 重點檢查這個就可以。數據庫問題解決後，可以看到爆紅的節點馬上變綠，整個系統恢復正常。
3. 架構方案
整個系統架構如上圖所示，每個被監控節點，均有對應的 agent 負責採集健康數據，不同的節點類型，採集的方式不一樣，web 節點提供 http 接口，agent 定時訪問，Redis 和 MQ 通過對應的 api，db 則採用標準的 jdbc。除了 web 應用有少量改造（提供一個接口），其他節點都無需改造，系統的侵入性很低。
Agent 每 5s 採集節點數據，由 monitor service 確定節點當前狀態並存儲，Dashboard 每 3s 拉取節點狀態並以紅黃綠三色展示，同時顯示具體出錯信息。
4. 落地效果
看下實際監控效果，下圖是某個業務系統的實際監控效果圖，左邊是系統部署架構，最上面是兩個前端應用，分別有自己的 Web 服務器（Docker 部署，所以只顯示一個節點實例），以及 MQ 和 Redis 中間件（有多個節點實例），這兩個應用同時依賴後端 3 個服務，實際節點部署情況和依賴關係一目瞭然。
圖中有一個節點是黃色狀態，原因是採樣時間內接口平均調用時間超過正常數倍。其他節點均正常，具體出錯信息在右邊列表有說明。點擊某個節點，會顯示該節點歷史出錯信息，可供進一步排查，這裏就不貼截圖了。
這是單個系統的監控，用一個單獨的頁面表示，如果一個公司有多達數十套系統，對應數十個頁面，monitor 肯定看不過來，屏幕牆物理空間也有限。這裏可以進一步做所有系統的大盤監控，每個系統在大盤上用一個方塊表示，同樣有紅黃綠三種狀態，這個狀態是根據該系統內所有節點狀態加權算出。
此外，如果具體節點實例有問題，會在大盤左側區域按照類別彙總顯示，出錯信息在大盤下方展示。這張圖兼顧宏觀和微觀，一方面直觀展示各個系統總體狀況，另一方面展示所有問題節點的出錯情況。Monitor 只要觀察這個大盤頁面就可以，如果發現某個系統有問題，可以點擊進去，看該系統詳細出錯情況。
下圖有一個系統處於紅色高危狀態，兩個系統是黃色警告狀態，引起這 3 個系統出問題的是 3 個 web 節點，在左邊顯示，具體出錯信息在最下面的錯誤列表。這裏系統狀態，節點狀態，錯誤消息均以紅黃綠表示，可以非常直觀地對應起來。
通過一體化地交通圖監控，可以快速定位到哪些節點有問題，通過依賴關係進一步確定問題源，並且有具體的出錯信息可以幫助定位原因，配合在一起，大大減少問題解決的時間。
5. 總結
交通圖監控有以下特點：
-
包含節點 ->應用 ->系統 ->大盤監控，層次鮮明，依賴清晰，實現一體化監控。
-
直觀地以紅黃綠展示節點狀態，每個人都能判斷哪裏有問題，以及問題原因。
-
本質上這是一個活的部署圖，實時反映系統狀態，並和實際部署一模一樣。
常規的監控工具，比如 Zabbix 和 APM，強調微觀，適合程序員排查具體問題。
交通圖監控強調更宏觀一些，自上而下地把監控對象組織在一起，把所有人拉到同一個信息層面，並提供直觀的手段標識問題，非常適合解決線上重大事故。
當然兩者完全可以結合起來，交通圖監控作爲監控大屏入口，常規監控作爲細節補充。在我們的節點詳情頁裏，也是有鏈接指向該節點的 Zabbix 和 CAT 監控頁面，可以幫助獲取錯誤詳細信息。