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

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

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

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

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

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

運(yùn)維平臺(tái)的升級(jí)，建議引入日志收集(如Fluentd)，分布式跟蹤(如Zipkin)和儀表盤(pán)(如Vizceral/Grafana)等;

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

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

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

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

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

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

通過(guò)變量的方式盡量減少人工輸入

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

通過(guò)故障演練驗(yàn)證報(bào)警是否符合預(yù)期

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

第三，服務(wù)故障的定位成本增加。假設(shè)故障是因?yàn)樘囟ǚ?wù)處理耗時(shí)增大導(dǎo)致的，那么如何快速?gòu)?06個(gè)服務(wù)以及眾多的第三方依賴(lài)中把它找出來(lái)，進(jìn)一步，又如何確認(rèn)是這個(gè)服務(wù)的單個(gè)實(shí)例還是部分實(shí)例的異常，這些都讓故障定位變得更復(fù)雜。

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

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

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

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

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

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

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

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

通過(guò)批量寫(xiě)入降低Hbase的寫(xiě)入壓力;

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

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

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

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

對(duì)監(jiān)控配置的合規(guī)性進(jìn)行強(qiáng)校驗(yàn);

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

支持配置的快速回滾。

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

解決這類(lèi)問(wèn)題的思路主要是如下方式：

基于報(bào)警接收人通過(guò)延時(shí)發(fā)送進(jìn)行合并;

報(bào)警策略添加依賴(lài)關(guān)系;

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

增加多種報(bào)警通知方式如電話、IM等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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