資訊專欄INFORMATION COLUMN
摘要：京東云監控響應實踐京東云運維平臺為數萬臺機器提供監控，部署，機器管理，權限管理，安全管理，審計和運營分析等功能，為京東云所有的業務在各類異構網絡環境下提供標準和統一的運維支撐能力。
微服務本身并沒有一個嚴格的定義，不過從很多人的反饋來看，大家都達成了這樣一個共識：微服務是一種簡單的應用，大概有10到100行代碼。我知道使用代碼行數來比較實現其實很不靠譜，因此你能理解這個意思就行，不必過分拘泥于細節。不過有一點需要注意，那就是微服務通常都是很小的，甚至是微型的。這意味著你不會在大型框架上看到很多小服務，這是不切實際的。簡單與輕量級是當今的主流。諸如Sinatra、Webbit、Finagle與Connect等小型框架在將你的代碼包裝到一個薄薄的通信層這方面做得剛剛好。
微服務架構帶來的變化
微服務架構給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的發展，在基礎設施的各個領域，都會從百花齊放到幾家獨大，從而將標準化落地到基礎設施的各個領域，進而促進整個生態的繁榮。
關注作者，我會不定期在思否分享Java，Spring，MyBatis，Netty源碼分析，高并發、高性能、分布式、微服務架構的原理，JVM性能優化、分布式架構，BATJ面試 等資料...
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/77712.html
摘要：北京時間月日月日，由和中國國際人才交流基金會聯合主辦的第七屆全球軟件案例研究峰會簡稱在北京國家會議中心圓滿落幕。本屆峰會，來自阿里美團百度平安銀行等企業的講師分別從企業轉型及研發效能方面分享敏捷和的實踐細節和操作經驗。 北京時間11月30日-12月3日，由msup和中國國際人才交流基金會聯合主辦的第七屆全球軟件案例研究峰會（簡稱：TOP100summit）在北京國家會議中心圓滿落幕。T...
摘要：對此，黃啟功表示，容器技術是虛擬化技術的演進結果，這也是企業架構變化的訴求。目前整個業界也在探索容器技術的標準問題，因為只有標準化之后才能被廣泛接受，并大規模在企業中推廣應用。 以Docker為代表的容器技術正在席卷整個IT業界，容器技術賦予了企業開發運維更多的敏捷性。而在以Docker為代表的容器虛擬化技術市場，初創公司紛紛開始瞄準這個領域進行創新開發，其中TenxCloud時速云就...
摘要：坎貝爾說我們已經看到，隨著團隊采用微服務，從提交到制作的周期時間顯著縮短。轉向微服務代表著一場大變革，各個組織需要做好應對這種重大轉變的準備。表示，企業還應考慮根據業務優先級為每個微服務的性能和可靠性定義服務水平協議。如今新應用程序的開發都與交付速度有關。向敏捷環境的大規模轉移已經持續了數年，這促使人們有一種輕松快速地部署軟件的意識。微服務是面向服務的體系結構（SOA）的一種變體，它將應用程...
閱讀 2576·2021-10-25 09:45
閱讀 1238·2021-10-14 09:43
閱讀 2297·2021-09-22 15:23
閱讀 1519·2021-09-22 14:58
閱讀 1934·2019-08-30 15:54
閱讀 3539·2019-08-30 13:00
閱讀 1354·2019-08-29 18:44
閱讀 1571·2019-08-29 16:59
