摘要：京東云監(jiān)控響應(yīng)實踐京東云運維平臺為數(shù)萬臺機器提供監(jiān)控，部署，機器管理，權(quán)限管理，安全管理，審計和運營分析等功能，為京東云所有的業(yè)務(wù)在各類異構(gòu)網(wǎng)絡(luò)環(huán)境下提供標(biāo)準(zhǔn)和統(tǒng)一的運維支撐能力。

微服務(wù)本身并沒有一個嚴(yán)格的定義，不過從很多人的反饋來看，大家都達(dá)成了這樣一個共識：微服務(wù)是一種簡單的應(yīng)用，大概有10到100行代碼。我知道使用代碼行數(shù)來比較實現(xiàn)其實很不靠譜，因此你能理解這個意思就行，不必過分拘泥于細(xì)節(jié)。不過有一點需要注意，那就是微服務(wù)通常都是很小的，甚至是微型的。這意味著你不會在大型框架上看到很多小服務(wù)，這是不切實際的。簡單與輕量級是當(dāng)今的主流。諸如Sinatra、Webbit、Finagle與Connect等小型框架在將你的代碼包裝到一個薄薄的通信層這方面做得剛剛好。

微服務(wù)架構(gòu)帶來的變化

微服務(wù)架構(gòu)給IT系統(tǒng)和團隊帶來了以下顯著的變化：

基礎(chǔ)設(shè)施的升級，需要引入虛擬化(如Docker)，現(xiàn)存基礎(chǔ)設(shè)施也需要與之進行適配;

系統(tǒng)架構(gòu)的升級，需要引入服務(wù)注冊(如Consul)，服務(wù)間的交互方式也需要與之進行適配;

運維平臺的升級，建議引入日志收集(如Fluentd)，分布式跟蹤(如Zipkin)和儀表盤(如Vizceral/Grafana)等;

運維效率和自動化水平的提升也迫在眉睫，否則無法應(yīng)對實例數(shù)量，變更頻率，系統(tǒng)復(fù)雜度的快速增長;

觀念的轉(zhuǎn)變，基礎(chǔ)設(shè)施，系統(tǒng)架構(gòu)和運維平臺等的大幅升級，猶如小米加步槍換成飛機大炮，相應(yīng)的戰(zhàn)略戰(zhàn)術(shù)也需要與之相適配才行。

微服務(wù)架構(gòu)下用戶面臨的監(jiān)控問題

在轉(zhuǎn)型到微服務(wù)架構(gòu)以后，用戶在監(jiān)控方面主要會面臨以下問題。

首先，監(jiān)控配置的維護成本增加。某個在線系統(tǒng)大概有106個模塊，每個模塊都需要添加端口監(jiān)控，進程監(jiān)控，日志監(jiān)控和自定義監(jiān)控;不同服務(wù)的監(jiān)控指標(biāo)，聚合指標(biāo)，報警閾值，報警依賴，報警接收人，策略級別，處理預(yù)案和備注說明也不完全相同;如此多的內(nèi)容，如何確保是否有效，是否生效，是否完整無遺漏。

當(dāng)前針對維護成本，業(yè)界常用的幾種方法有：

通過變量的方式盡量減少人工輸入

通過監(jiān)控配置文件解析做一些可標(biāo)準(zhǔn)化的校驗

通過故障演練驗證報警是否符合預(yù)期

其次，第三方依賴越來越多。例如Docker的可靠性很大程度上取決于宿主機，如果所在的宿主機發(fā)生資源爭用，網(wǎng)絡(luò)異常，硬件故障，修改內(nèi)核參數(shù)，操作系統(tǒng)補丁升級等，都可能會讓Docker莫名其妙地中招。

第三，服務(wù)故障的定位成本增加。假設(shè)故障是因為特定服務(wù)處理耗時增大導(dǎo)致的，那么如何快速從106個服務(wù)以及眾多的第三方依賴中把它找出來，進一步，又如何確認(rèn)是這個服務(wù)的單個實例還是部分實例的異常，這些都讓故障定位變得更復(fù)雜。

在微服務(wù)架構(gòu)下，提高故障定位效率的常用方法有：基于各類日志分析，通過儀表盤展示核心指標(biāo)：數(shù)據(jù)流，異常的監(jiān)控策略，變更內(nèi)容，線上登錄和操作記錄，文件修改等內(nèi)容。

微服務(wù)監(jiān)控的難點及解決思路

在微服務(wù)架構(gòu)下，監(jiān)控系統(tǒng)在報警時效性不可改變的前提下，采集的指標(biāo)數(shù)量是傳統(tǒng)監(jiān)控的三倍以上，如果是萬臺以上的規(guī)模，監(jiān)控系統(tǒng)整體都面臨非常大的壓力，在監(jiān)控方面的挑戰(zhàn)主要來源于：

首先，存儲功能的寫入壓力和可用性都面臨巨大挑戰(zhàn)。每秒寫入幾十萬采集項并且需要保證99.99%的可用性，對于任何存儲軟件來講，都不是一件輕松的事情。

對于寫入和可用性的壓力，業(yè)界常見的解決思路主要是基于如下方式的組合：

集群基于各種維度進行拆分(如地域維度、功能維度和產(chǎn)品維度等);

增加緩存服務(wù)來降低Hbase的讀寫壓力;

調(diào)整使用頻率較低指標(biāo)的采集周期;

通過批量寫入降低Hbase的寫入壓力;

通過寫入兩套Hbase避免數(shù)據(jù)丟失并做到故障后快速切換。

其次，監(jiān)控的生效速度也面臨巨大挑戰(zhàn)。微服務(wù)架構(gòu)下，基于彈性伸縮的加持，從服務(wù)擴容或者遷移完畢到接入流量的耗時降低到1Min左右，且每時每刻都在不斷發(fā)生著。對于復(fù)雜監(jiān)控系統(tǒng)來講，支持這樣的變更頻率絕非易事，而且實例變更如此頻繁，對監(jiān)控系統(tǒng)自身來講，也會面臨可用性的風(fēng)險。

常見的提高監(jiān)控生效速度的思路主要有如下的幾種方式：

實時熱加載服務(wù)注冊信息;

對監(jiān)控配置的合規(guī)性進行強校驗;

增加實例數(shù)量的閾值保護;

支持配置的快速回滾。

第三，基礎(chǔ)設(shè)施的故障可能導(dǎo)致報警風(fēng)暴的發(fā)生。基礎(chǔ)設(shè)施如IDC故障，可能會在瞬時產(chǎn)生海量報警，進而導(dǎo)致短信網(wǎng)關(guān)擁塞較長時間。

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

基于報警接收人通過延時發(fā)送進行合并;

報警策略添加依賴關(guān)系;

優(yōu)先發(fā)送嚴(yán)重故障的報警短信;

增加多種報警通知方式如電話、IM等。

微服務(wù)監(jiān)控原則

對于采用微服務(wù)的團隊，建議在做監(jiān)控時可以參考Google SRE的理論，結(jié)合長期的運維實踐經(jīng)驗，我們總結(jié)了幾點可以參考的原則：

首先，所有系統(tǒng)和第三方依賴的核心功能必須添加黑盒監(jiān)控;

第二，所有模塊必須添加白盒監(jiān)控的四個黃金指標(biāo)(飽和度，錯誤，流量和延時);

第三，所有的變更都需要進行采集，包括但不限于程序，配置，數(shù)據(jù)，網(wǎng)絡(luò)，硬件，操作系統(tǒng)以及各類基礎(chǔ)設(shè)施。

另外，我們也給大家提供了一些黑盒監(jiān)控的實施經(jīng)驗：

首先，應(yīng)該監(jiān)控哪些功能?建議將系統(tǒng)接入層的訪問日志，TOP-10的URL添加黑盒監(jiān)控。那TOP-9的URL是否一定需要監(jiān)控?TOP-11的URL是否一定不需要監(jiān)控?這取決于其訪問量是否和前面的URL在一個數(shù)量級以及人工評估其接口的重要性程度，這里提供的更多是一個思路，而非可量化的方法。

第二，應(yīng)該使用多少個樣本/節(jié)點對一個功能進行黑盒監(jiān)控?建議樣本應(yīng)該覆蓋到對應(yīng)模塊的所有實例，這樣也能發(fā)現(xiàn)由少數(shù)實例導(dǎo)致的小規(guī)模故障。

微服務(wù)架構(gòu)下的理想監(jiān)控系統(tǒng)

從用戶的角度看，Prometheus的整體架構(gòu)設(shè)計參考了Google BorgMon，系統(tǒng)具有高度的靈活性，圍繞其開放性現(xiàn)在也慢慢形成了一個生態(tài)系統(tǒng)。具體來說，Prometheus 使用的是 Pull 模型，Prometheus Server 通過 HTTP 的 Pull 方式到各個目標(biāo)拉取監(jiān)控數(shù)據(jù)。HTTP協(xié)議的支持能夠更加方便的進行定制化開發(fā)，服務(wù)注冊、信息采集和數(shù)據(jù)展示均支持多種形式/開源軟件。

結(jié)合目前國內(nèi)正在興起的智能運維，也許不久的將來，上面提到的監(jiān)控的各種問題也就迎刃而解了。監(jiān)控策略不在需要人工定義，轉(zhuǎn)由機器學(xué)習(xí)負(fù)責(zé)，諸如策略添加，閾值設(shè)定，異常檢測，故障定位，自動止損等逐步由系統(tǒng)負(fù)責(zé)，運維人員不再是“救火隊長”。

京東云監(jiān)控響應(yīng)實踐

京東云運維平臺為數(shù)萬臺機器提供監(jiān)控，部署，機器管理，權(quán)限管理，安全管理，審計和運營分析等功能，為京東云所有的業(yè)務(wù)在各類異構(gòu)網(wǎng)絡(luò)環(huán)境下提供標(biāo)準(zhǔn)和統(tǒng)一的運維支撐能力。

基于產(chǎn)品所處的發(fā)展階段，用戶規(guī)模的不同，報警頻率也不盡相同。理想情況下，報警頻率應(yīng)該等同于故障頻率，這里面體現(xiàn)了報警的準(zhǔn)確度和召回率兩個指標(biāo)，如果每個報警都對應(yīng)一個服務(wù)故障，則準(zhǔn)確度為100%，同理，如果每次服務(wù)故障均有報警產(chǎn)生，則召回率為100%。大家可以基于上述兩個指標(biāo)，來衡量自己團隊的現(xiàn)狀，并針對性的制定提升計劃即可。

對于響應(yīng)流程，京東云有幾個做的好的地方可以給大家參考：

首先，所有核心報警均有可靠的應(yīng)對預(yù)案和處理機制，并通過定期的破壞演練持續(xù)進行完善。

其次，公司的監(jiān)控中心會7x24值守，他們也會和業(yè)務(wù)線運維同學(xué)一樣，接收所有影響核心系統(tǒng)穩(wěn)定性的報警，收到報警后會進行通報，確保核心報警在發(fā)生后第一時間內(nèi)有人處理并在規(guī)定的時間內(nèi)處理完畢。如果未在規(guī)定的時間內(nèi)處理完畢，監(jiān)控中心會進行報警升級，通報該系統(tǒng)的管理人員，從而確保該報警可以得到更高的重視度和支持力度。

總結(jié)

對于監(jiān)控系統(tǒng)的未來發(fā)展，長期來看，依托于Kubernetes的發(fā)展，在基礎(chǔ)設(shè)施的各個領(lǐng)域，都會從百花齊放到幾家獨大，從而將標(biāo)準(zhǔn)化落地到基礎(chǔ)設(shè)施的各個領(lǐng)域，進而促進整個生態(tài)的繁榮。

關(guān)注作者，我會不定期在思否分享Java，Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化、分布式架構(gòu)，BATJ面試 等資料...