微服務是一種架構風格，一個大型復雜軟件應用通常由多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關註於完成一件任務並很好地完成該任務。

微服務之前很多單體應用，其監控復雜度較低，場景也比較單一。微服務下，由於業務邏輯散布在眾多進程中（很多大型業務，一個業務流程涉及的服務有幾十個），一旦業務出現問題，追查其源頭就好比大海撈針，這個時候就需要完善的監控體系。

一個完善的監控體系，其構建周期比較漫長，而且隨著業務場景的變化，自身也是需要不斷叠代優化的。本文僅從幾個監控維度以及原子化場景談談如何建立統一的監控數據收集、展示系統，希望能夠啟發大家繼續深入地思考監控體系的建設。

微服務下的幾個監控維度

微服務監控與傳統應用的監控相比，最明顯的改變就是視角的改變，我們把監控從機器視角轉換成以服務為中心的視角，在微服務的視角下，監控可以從數據維度、資源維度和代碼維度進行分層，如下圖：

數據維度

當前WEB化服務是主流，每一個WEB服務都有一個入口，不管是APP還是WEB網頁，入口負責跟用戶交互，並將用戶的信息發給後臺，後臺一般都會有接入LB或者Gateway，負責負載均衡並將數據轉發給具體的應用處理，最後由應用處理之後寫入數據庫。

資源維度

現在很多服務部署在雲端，涉及虛擬化技術，虛擬主機運行在物理服務器上，虛擬主機之間通過虛擬網絡相互連接。在資源層面的監控，是不可缺少的一環，我們不但需要采集虛擬主機的性能指標，同時還需要知道運行虛擬主機的服務器上的CPU、內存、磁盤IO等數據，以及連接虛擬主機之間的虛擬網絡的帶寬負載等。

代碼維度

APM，也就是應用性能分析，代碼側的監控采集，是隨著微服務的興起而出現的。在微服務場景下，一個業務流程橫跨幾十個服務的場景，只有傳統的監控數據，很難定位到問題的根源。

我們可以針對代碼的技術棧，開發出特定的采集框架，在性能損耗可以接受的範圍之內，采集函數之間的調用關系，服務之間的調用拓撲，並測量函數或者服務的響應時間，才能有針對性地優化性能或者提前預判故障。

關鍵監控指標的場景描述

微服務監控最大的特點，用一句話概括：就是服務特別多，服務間的調用也非常復雜。當系統出現問題時，想要在上百個相關的、依賴錯綜復雜的服務系統之中快速定位到出錯的系統，需要依靠關鍵的監控指標。我們在上述的三個維度之上，分析了每個維度下每個層級可能會產生的告警情況，總結了URL監控、主機監控、產品監控等八個原子化監控場景。

URL監控：無論是APP還是WEB，本質上都是通過URL發起後臺調用，可以通過MOCK調用API獲取響應時間、響應狀態碼等指標，展示監測業務的整體健康狀況。

主機監控：通過安裝代理采集主機上基本的監控信息如CPU、內存、IO等數據，同時用戶可以通過配置文件打開其它開源應用如Tomcat、Nginx等數據采集開關。

產品監控：公有雲將主機、網絡、存儲以及一些中間件以產品的形式提供給用戶使用，產品服務後臺上報各個產品相關指標數據，用來監控各個產品資源的健康狀況。

組件監控：一些開源組件，比如Tomcat、Nginx、Netty等監控數據的采集，可以通過主機上的代理加載相應組件的監控采集程序。

自定義監控：服務實例收集業務相關數據，定時調用API接口上報數據，支持多個服務實例同時上報一個監控項，並且支持多維度查詢告警。

資源監控：用戶以資源為維度上報自定義數據，每個資源都有相同的幾個監控項，各個資源的監控項之間相互獨立。

APM：根據各語言棧的不同，分別實現函數調用關系、服務之間調用拓撲的展示。根據各個語言的不同，有的需要***代碼，以SDK嵌入的形式收集數據，有的則與代碼解耦，通過元編程重載一些方法來實現數據采集。

事件監控：針對公有雲產品、業務邏輯中的不連續事件，比如雲盤的不可用事件、SSD硬盤的Reset事件等，提供統一的存儲、分析、展示。

有了以上原子化場景的數據收集，我們就可以通過UI統一展示監控數據，可以按照前文描述的三個維度，以用戶體驗為核心，設計圖形化頁面。圖形化一般是以時間序列為橫軸，展示指標隨時間變化，針對一些統計指標，也可以通過餅圖、柱狀圖等展示分析、對比結果。

本文主要闡述了監控體系中數據的采集、展示。至於數據的存儲及告警流程，有興趣的同學可以繼續關註後續監控相關文章。

作者介紹

董磊：UCloud技術專家。十年IT行業開發經驗，目前負責UCloud混合雲、監控產品的設計開發，持續關註微服務架構、監控、DevOps等領域。

*更多技術幹貨，歡迎微信關註“UCloud技術公告牌”查看。

微服務架構下的監控系統設計（一）——指標數據的采集展示