微服務架構下的監控需要注意哪些方面？
本期我們重點講述微服務架構下的監控
微服務架構雖然誕生的時間并不長，卻因為適應現今互聯網的高速發展和敏捷、DevOps等文化而受到很多企業的推崇。微服務架構在帶來靈活性、擴展性、伸縮性以及高可用性等優點的同時，其復雜性也給運維工作中最重要的監控環節帶來了很大的挑戰：海量日志數據如何處理，服務如何追蹤，如何高效定位故障縮短故障時長……今天，我們就來談一談微服務架構下的監控應該注意哪些方面。
微服務架構帶來的變化
微服務架構給IT系統和團隊帶來了以下顯著的變化：
- 基礎設施的升級，需要引入虛擬化(如Docker)，現存基礎設施也需要與之進行適配;
- 系統架構的升級，需要引入服務注冊(如Consul)，服務間的交互方式也需要與之進行適配;
- 運維平臺的升級，建議引入日志收集(如Fluentd)，分布式跟蹤(如Zipkin)和儀表盤(如Vizceral/Grafana)等;
- 運維效率和自動化水平的提升也迫在眉睫，否則無法應對實例數量，變更頻率，系統復雜度的快速增長;
- 觀念的轉變，基礎設施，系統架構和運維平臺等的大幅升級，相應的戰略戰術也需要與之相適配才行。
微服務架構下用戶面臨的監控問題
在轉型到微服務架構以后，用戶在監控方面主要會面臨以下問題。
首先，監控配置的維護成本增加。某個在線系統大概有106個模塊，每個模塊都需要添加端口監控，進程監控，日志監控和自定義監控;不同服務的監控指標，聚合指標，報警閾值，報警依賴，報警接收人，策略級別，處理預案和備注說明也不完全相同;如此多的內容，如何確保是否有效，是否生效，是否完整無遺漏。
當前針對維護成本，業界常用的幾種方法有：
- 通過變量的方式盡量減少人工輸入
- 通過監控配置文件解析做一些可標準化的校驗
- 通過故障演練驗證報警是否符合預期
其次，第三方依賴越來越多。例如Docker的可靠性很大程度上取決于宿主機，如果所在的宿主機發生資源爭用，網絡異常，硬件故障，修改內核參數，操作系統補丁升級等，都可能會讓Docker莫名其妙地中招。
第三，服務故障的定位成本增加。假設故障是因為特定服務處理耗時增大導致的，那么如何快速從106個服務以及眾多的第三方依賴中把它找出來，進一步，又如何確認是這個服務的單個實例還是部分實例的異常，這些都讓故障定位變得更復雜。
在微服務架構下，提高故障定位效率的常用方法有：基于各類日志分析，通過儀表盤展示核心指標：數據流，異常的監控策略，變更內容，線上登錄和操作記錄，文件修改等內容。
微服務監控的難點及解決思路
在微服務架構下，監控系統在報警時效性不可改變的前提下，采集的指標數量是傳統監控的三倍以上，如果是萬臺以上的規模，監控系統整體都面臨非常大的壓力，在監控方面的挑戰主要來源于：
首先，存儲功能的寫入壓力和可用性都面臨巨大挑戰。每秒寫入幾十萬采集項并且需要保證99.99%的可用性，對于任何存儲軟件來講，都不是一件輕松的事情。
對于寫入和可用性的壓力，業界常見的解決思路主要是基于如下方式的組合：
- 集群基于各種維度進行拆分(如地域維度、功能維度和產品維度等);
- 增加緩存服務來降低Hbase的讀寫壓力;
- 調整使用頻率較低指標的采集周期;
- 通過批量寫入降低Hbase的寫入壓力;
- 通過寫入兩套Hbase避免數據丟失并做到故障后快速切換。
其次，監控的生效速度也面臨巨大挑戰。微服務架構下，基于彈性伸縮的加持，從服務擴容或者遷移完畢到接入流量的耗時降低到1Min左右，且每時每刻都在不斷發生著。對于復雜監控系統來講，支持這樣的變更頻率絕非易事，而且實例變更如此頻繁，對監控系統自身來講，也會面臨可用性的風險。
常見的提高監控生效速度的思路主要有如下的幾種方式：
- 實時熱加載服務注冊信息;
- 對監控配置的合規性進行強校驗;
- 增加實例數量的閾值保護;
- 支持配置的快速回滾。
第三，基礎設施的故障可能導致報警風暴的發生。基礎設施如IDC故障，可能會在瞬時產生海量報警，進而導致短信網關擁塞較長時間。
解決這類問題的思路主要是如下方式：
- 基于報警接收人通過延時發送進行合并;
- 報警策略添加依賴關系;
- 優先發送嚴重故障的報警短信;
- 增加多種報警通知方式如電話、IM等。
微服務監控原則
對于采用微服務的團隊，建議在做監控時可以參考Google SRE的理論，結合長期的運維實踐經驗，我們總結了幾點可以參考的原則：
- 首先，所有系統和第三方依賴的核心功能必須添加黑盒監控;
- 第二，所有模塊必須添加白盒監控的四個黃金指標(飽和度，錯誤，流量和延時);
- 第三，所有的變更都需要進行采集，包括但不限于程序，配置，數據，網絡，硬件，操作系統以及各類基礎設施。
另外，我們也給大家提供了一些黑盒監控的實施經驗：
首先，應該監控哪些功能?建議將系統接入層的訪問日志，URL添加黑盒監控。那TOP-9的URL是否一定需要監控?URL是否一定不需要監控?這取決于其訪問量是否和前面的URL在一個數量級以及人工評估其接口的重要性程度，這里提供的更多是一個思路，而非可量化的方法。
第二，應該使用多少個樣本/節點對一個功能進行黑盒監控?建議樣本應該覆蓋到對應模塊的所有實例，這樣也能發現由少數實例導致的小規模故障。
微服務架構下的理想監控系統
從用戶的角度看，Prometheus的整體架構設計參考了Google BorgMon，系統具有高度的靈活性，圍繞其開放性現在也慢慢形成了一個生態系統。具體來說，Prometheus 使用的是 Pull 模型，Prometheus Server 通過 HTTP 的 Pull 方式到各個目標拉取監控數據。HTTP協議的支持能夠更加方便的進行定制化開發，服務注冊、信息采集和數據展示均支持多種形式/開源軟件。
結合目前國內正在興起的智能運維，也許不久的將來，上面提到的監控的各種問題也就迎刃而解了。監控策略不在需要人工定義，轉由機器學習負責，諸如策略添加，閾值設定，異常檢測，故障定位，自動止損等逐步由系統負責，運維人員不再是“救火隊長”。
京東云監控響應實踐
京東云運維平臺為數萬臺機器提供監控，部署，機器管理，權限管理，安全管理，審計和運營分析等功能，為京東云所有的業務在各類異構網絡環境下提供標準和統一的運維支撐能力。
基于產品所處的發展階段，用戶規模的不同，報警頻率也不盡相同。理想情況下，報警頻率應該等同于故障頻率，這里面體現了報警的準確度和召回率兩個指標，如果每個報警都對應一個服務故障，則準確度為100%，同理，如果每次服務故障均有報警產生，則召回率為100%。大家可以基于上述兩個指標，來衡量自己團隊的現狀，并針對性的制定提升計劃即可。
對于響應流程，京東云有幾個做的好的地方可以給大家參考：
首先，所有核心報警均有可靠的應對預案和處理機制，并通過定期的破壞演練持續進行完善。
其次，公司的監控中心會7x24值守，他們也會和業務線運維同學一樣，接收所有影響核心系統穩定性的報警，收到報警后會進行通報，確保核心報警在發生后有人處理并在規定的時間內處理完畢。如果未在規定的時間內處理完畢，監控中心會進行報警升級，通報該系統的管理人員，從而確保該報警可以得到更高的重視度和支持力度。
總結
對于監控系統的未來發展，長期來看，依托于Kubernetes的發展，在基礎設施的各個領域，都會從百花齊放到幾家獨大，從而將標準化落地到基礎設施的各個領域，進而促進整個生態的繁榮。
在監控方向，Prometheus在未來一段時間后，也許會是一個很好的選擇。在Prometheus等工具解決了通用的監控場景并標準化之后，在其上的各類應用場景，如容量規劃，流量監控，故障定位以及各種基于大數據和人工智能場景的落地等，就會出現百花齊放之勢。
【本文為51CTO專欄作者“京東云”的原創稿件，轉載請通過作者微信公眾號JD-jcloud獲取授權】
