微服務架構在帶來靈活性、擴展性、伸縮性以及高可用性等優點的同時，其複雜性也給運維工作中最重要的監控環節帶來了很大的挑戰，從用戶的角度看，微服務架構下的監控應該注意哪些方面？
微服務架構雖然誕生的時間並不長，卻因爲適應現今互聯網的高速發展和敏捷、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等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！