微服務架構下的監控須要注意哪些方面？

微服務架構在帶來靈活性、擴展性、伸縮性以及高可用性等優勢的同時，其複雜性也給運維工做中最重要的監控環節帶來了很大的挑戰，從用戶的角度看，微服務架構下的監控應該注意哪些方面？ 微服務架構雖然誕生的時間並不長，卻由於適應現今互聯網的高速發展和敏捷、DevOps 等文化而受到不少企業的推崇。微服務架構在帶來靈活性、擴展性、伸縮性以及高可用性等優勢的同時，其複雜性也給運維工做中最重要的監控環節帶來了很大的挑戰：海量日誌數據如何處理，服務如何追蹤，如何高效定位故障縮短故障時常……

InfoQ 記者採訪了京東雲應用研發部門運維負責人，來談一談微服務架構下的監控應該注意哪些方面。

微服務架構帶來的變化 在京東雲運維專家看來，微服務架構給 IT 系統和團隊帶來了如下顯著的變化：

基礎設施的升級，須要引入虛擬化（如 Docker），現存基礎設施也須要與之進行適配；

系統架構的升級，須要引入服務註冊（如 Consul），服務間的交互方式也須要與之進行適配；

運維平臺的升級，建議引入日誌收集（如 Fluentd），分佈式跟蹤（如 Zipkin）和儀表盤（如 Vizceral/Grafana）等；

運維效率和自動化水平的提高也迫在眉睫，不然沒法應對實例數量，變動頻率，系統複雜度的快速增加；

觀念的轉變，基礎設施，系統架構和運維平臺等的大幅升級，猶如小米加步槍換成飛機大炮，相應的戰略戰術也須要與之相適配才行。

微服務架構下用戶面臨的監控問題 在轉型到微服務架構之後，用戶在監控方面主要會面臨如下問題。

首先，監控配置的維護成本增長。某個在線系統大概有 106 個模塊，每一個模塊都須要添加端口監控，進程監控，日誌監控和自定義監控；不一樣服務的監控指標，聚合指標，報警閾值，報警依賴，報警接收人，策略級別，處理預案和備註說明也不徹底相同；如此多的內容，如何確保是否有效，是否生效，是否完整無遺漏。當前針對維護成本，業界經常使用的幾種方法有：

經過變量的方式儘可能減小人工輸入；

經過監控配置文件解析作一些可標準化的校驗；

經過故障演練驗證報警是否符合預期；

其次，第三方依賴愈來愈多。例如 Docker 的可靠性很大程度上取決於宿主機，若是所在的宿主機發生資源爭用，網絡異常，硬件故障，修改內核參數，操做系統補丁升級等，均可能會讓 Docker 莫名其妙地中招。

第三，服務故障的定位成本增長。假設故障是由於特定服務處理耗時增大致使的，那麼如何快速從 106 個服務以及衆多的第三方依賴中把它找出來，進一步，又如何確認是這個服務的單個實例仍是部分實例的異常，這些都讓故障定位變得更復雜。

在微服務架構下，提升故障定位效率的經常使用方法有：基於各種日誌分析，經過儀表盤展現核心指標：數據流，異常的監控策略，變動內容，線上登陸和操做記錄，文件修改等內容。

微服務監控的難點及解決思路 在微服務架構下，監控系統在報警時效性不可改變的前提下，採集的指標數量是傳統監控的三倍以上，若是是萬臺以上的規模，監控系統總體都面臨很是大的壓力，在監控方面的挑戰主要來源於：

首先，存儲功能的寫入壓力和可用性都面臨巨大挑戰。每秒寫入幾十萬採集項而且須要保證 99.99% 的可用性，對於任何存儲軟件來說，都不是一件輕鬆的事情。對於寫入和可用性的壓力，業界常見的解決思路主要是基於以下方式的組合：

集羣基於各類維度進行拆分（如地域維度、功能維度和產品維度等）；

增長緩存服務來下降 Hbase 的讀寫壓力；

調整使用頻率較低指標的採集週期；

經過批量寫入下降 Hbase 的寫入壓力；

經過寫入兩套 Hbase 避免數據丟失並作到故障後快速切換。

其次，監控的生效速度也面臨巨大挑戰。微服務架構下，基於彈性伸縮的加持，從服務擴容或者遷移完畢到接入流量的耗時下降到 1Min 左右，且每時每刻都在不斷髮生着。對於複雜監控系統來說，支持這樣的變動頻率絕非易事，並且實例變動如此頻繁，對監控系統自身來說，也會面臨可用性的風險。

常見的提升監控生效速度的思路主要有以下的幾種方式：

實時熱加載服務註冊信息；

對監控配置的合規性進行強校驗；

增長實例數量的閾值保護；

支持配置的快速回滾。

第三，基礎設施的故障可能致使報警風暴的發生。基礎設施如 IDC 故障，可能會在瞬時產生海量報警，進而致使短信網關擁塞較長時間。

解決這類問題的思路主要是以下方式：

基於報警接收人經過延時發送進行合併；

報警策略添加依賴關係；

優先發送嚴重故障的報警短信；

增長多種報警通知方式如電話，IM 等。

微服務監控原則 對於採用微服務的團隊，京東雲運維專家建議在作監控時能夠參考 Google SRE 的理論，結合本身長期的運維實踐經驗，他總結了幾點能夠參考的原則：

首先，全部系統和第三方依賴的核心功能必須添加黑盒監控；

第二，全部模塊必須添加白盒監控的四個黃金指標（飽和度，錯誤，流量和延時）；

第三，全部的變動都須要進行採集，包括但不限於程序，配置，數據，網絡，硬件，操做系統以及各種基礎設施。

另外，京東雲運維專家也給你們提供了一些黑盒監控的實施經驗：

首先，應該監控哪些功能？建議將系統接入層的訪問日誌，TOP-10 的 URL 添加黑盒監控。那 TOP-9 的 URL 是否必定須要監控？TOP-11 的 URL 是否必定不須要監控？這取決於其訪問量是否和前面的 URL 在一個數量級以及人工評估其接口的重要性程度，這裏提供的更可能是一個思路，而非可量化的方法。

第二，應該使用多少個樣本 / 節點對一個功能進行黑盒監控？建議樣本應該覆蓋到對應模塊的全部實例，這樣也能發現由少數實例致使的小規模故障。

微服務架構下的理想監控系統 從用戶的角度看，Prometheus 的總體架構設計參考了 Google BorgMon，系統具備高度的靈活性，圍繞其開放性如今也慢慢造成了一個生態系統。具體來講，Prometheus 使用的是 Pull 模型，Prometheus Server 經過 HTTP 的 Pull 方式到各個目標拉取監控數據。HTTP 協議的支持可以更加方便的進行定製化開發，服務註冊、信息採集和數據展現均支持多種形式 / 開源軟件。

結合目前國內正在興起的智能運維，也許不久的未來，上面提到的監控的各類問題也就迎刃而解了。監控策略不在須要人工定義，轉由機器學習負責，諸如策略添加，閾值設定，異常檢測，故障定位，自動止損等逐步由系統負責，運維人員再也不是「救火隊長」。

京東雲監控響應實踐 京東雲運維平臺爲數萬臺機器提供監控，部署，機器管理，權限管理，安全管理，審計和運營分析等功能，爲京東雲全部的業務在各種異構網絡環境下提供標準和統一的運維支撐能力。

基於產品所處的發展階段，用戶規模的不一樣，報警頻率也不盡相同。理想狀況下，報警頻率應該等同於故障頻率，這裏面體現了報警的準確度和召回率兩個指標，若是每一個報警都對應一個服務故障，則準確度爲 100%，同理，若是每次服務故障均有報警產生，則召回率爲 100%。你們能夠基於上述兩個指標，來衡量本身團隊的現狀，並針對性的制定提高計劃便可。

對於響應流程，京東雲有幾個作的好的地方能夠給你們參考。

首先，全部核心報警均有可靠的應對預案和處理機制，並經過按期的破壞演練持續進行完善。

其次，公司的監控中心會 7x24 值守，他們也會和業務線運維同窗同樣，接收全部影響核心系統穩定性的報警，收到報警後會進行通報，確保核心報警在發生後第一時間內有人處理並在規定的時間內處理完畢。若是未在規定的時間內處理完畢，監控中心會進行報警升級，通報該系統的管理人員，從而確保該報警能夠獲得更高的重視度和支持力度。

結語 對於監控系統的將來發展，京東雲的運維專家認爲長期來看，依託於 Kubernetes 的發展，在基礎設施的各個領域，都會從百花齊放到幾家獨大，從而將標準化落地到基礎設施的各個領域，進而促進整個生態的繁榮。

在監控方向，Prometheus 在將來一段時間後，也許會是一個很好的選擇。在 Prometheus 等工具解決了通用的監控場景並標準化以後，在其上的各種應用場景，如容量規劃，流量監控，故障定位以及各類基於大數據和人工智能場景的落地等，就會出現百花齊放之勢。

本文彩蛋 監控系統是整個 IT 架構中的重中之重，小到故障排查、問題定位，大到業務預測、運營管理，都離不開監控系統，能夠說一個穩定、健康的 IT 架構中必然會有一個可信賴的監控系統。 歡迎工做一到五年的Java工程師朋友們加入Java程序員開發： 854393687 羣內提供免費的Java架構學習資料（裏面有高可用、高併發、高性能及分佈式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用本身每一分每一秒的時間來學習提高本身，不要再用"沒有時間「來掩飾本身思想上的懶惰！趁年輕，使勁拼，給將來的本身一個交代！