前言
微服務是一種架構風格，一個大型複雜軟體應用通常由多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。
微服務之前很多單體應用，其監控複雜度較低，場景也比較單一。微服務下，由於業務邏輯散佈在眾多程式中（很多大型業務，一個業務流程涉及的服務有幾十個），一旦業務出現問題，追查其源頭就好比大海撈針，這個時候就需要完善的監控體系。
一個完善的監控體系，其構建週期比較漫長，而且隨著業務場景的變化，自身也是需要不斷迭代優化的。本文僅從幾個監控維度以及原子化場景談談如何建立統一的監控資料收集、展示系統，希望能夠啟發大家繼續深入地思考監控體系的建設。
微服務下的幾個監控維度
微服務監控與傳統應用的監控相比，最明顯的改變就是視角的改變，我們把監控從機器視角轉換成以服務為中心的視角，在微服務的視角下，監控可以從資料維度、資源維度和程式碼維度進行分層，如下圖：
資料維度
當前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技術公告牌” 檢視。