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

前言

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

微服務以前不少單體應用，其監控複雜度較低，場景也比較單一。微服務下，因爲業務邏輯散佈在衆多進程中（不少大型業務，一個業務流程涉及的服務有幾十個），一旦業務出現問題，追查其源頭就比如大海撈針，這個時候就須要完善的監控體系。

一個完善的監控體系，其構建週期比較漫長，並且隨着業務場景的變化，自身也是須要不斷迭代優化的。本文僅從幾個監控維度以及原子化場景談談如何創建統一的監控數據收集、展現系統，但願可以啓發你們繼續深刻地思考監控體系的建設。

微服務下的幾個監控維度

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

數據維度

當前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技術公告牌」查看。