微服務(wù)架構(gòu)下的監(jiān)控需要注意哪些方面？
本期我們重點(diǎn)講述微服務(wù)架構(gòu)下的監(jiān)控
微服務(wù)架構(gòu)雖然誕生的時(shí)間并不長(zhǎng)，卻因?yàn)檫m應(yīng)現(xiàn)今互聯(lián)網(wǎng)的高速發(fā)展和敏捷、DevOps等文化而受到很多企業(yè)的推崇。微服務(wù)架構(gòu)在帶來(lái)靈活性、擴(kuò)展性、伸縮性以及高可用性等優(yōu)點(diǎn)的同時(shí)，其復(fù)雜性也給運(yùn)維工作中最重要的監(jiān)控環(huán)節(jié)帶來(lái)了很大的挑戰(zhàn)：海量日志數(shù)據(jù)如何處理，服務(wù)如何追蹤，如何高效定位故障縮短故障時(shí)長(zhǎng)……今天，我們就來(lái)談一談微服務(wù)架構(gòu)下的監(jiān)控應(yīng)該注意哪些方面。
微服務(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)和儀表盤(如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í)，相應(yīng)的戰(zhàn)略戰(zhàn)術(shù)也需要與之相適配才行。
微服務(wù)架構(gòu)下用戶面臨的監(jiān)控問題
在轉(zhuǎn)型到微服務(wù)架構(gòu)以后，用戶在監(jiān)控方面主要會(huì)面臨以下問題。
首先，監(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)警依賴，報(bào)警接收人，策略級(jí)別，處理預(yù)案和備注說(shuō)明也不完全相同;如此多的內(nèi)容，如何確保是否有效，是否生效，是否完整無(wú)遺漏。
當(dāng)前針對(duì)維護(hù)成本，業(yè)界常用的幾種方法有：
- 通過變量的方式盡量減少人工輸入
- 通過監(jiān)控配置文件解析做一些可標(biāo)準(zhǔn)化的校驗(yàn)
- 通過故障演練驗(yàn)證報(bào)警是否符合預(yù)期
其次，第三方依賴越來(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)，進(jìn)一步，又如何確認(rèn)是這個(gè)服務(wù)的單個(gè)實(shí)例還是部分實(shí)例的異常，這些都讓故障定位變得更復(fù)雜。
在微服務(wù)架構(gòu)下，提高故障定位效率的常用方法有：基于各類日志分析，通過儀表盤展示核心指標(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ǔ)功能的寫入壓力和可用性都面臨巨大挑戰(zhàn)。每秒寫入幾十萬(wàn)采集項(xiàng)并且需要保證99.99%的可用性，對(duì)于任何存儲(chǔ)軟件來(lái)講，都不是一件輕松的事情。
對(duì)于寫入和可用性的壓力，業(yè)界常見的解決思路主要是基于如下方式的組合：
- 集群基于各種維度進(jìn)行拆分(如地域維度、功能維度和產(chǎn)品維度等);
- 增加緩存服務(wù)來(lái)降低Hbase的讀寫壓力;
- 調(diào)整使用頻率較低指標(biāo)的采集周期;
- 通過批量寫入降低Hbase的寫入壓力;
- 通過寫入兩套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)控生效速度的思路主要有如下的幾種方式：
- 實(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í)間。
解決這類問題的思路主要是如下方式：
- 基于報(bào)警接收人通過延時(shí)發(fā)送進(jìn)行合并;
- 報(bào)警策略添加依賴關(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)和第三方依賴的核心功能必須添加黑盒監(jiān)控;
- 第二，所有模塊必須添加白盒監(jiān)控的四個(gè)黃金指標(biāo)(飽和度，錯(cuò)誤，流量和延時(shí));
- 第三，所有的變更都需要進(jìn)行采集，包括但不限于程序，配置，數(shù)據(jù)，網(wǎng)絡(luò)，硬件，操作系統(tǒng)以及各類基礎(chǔ)設(shè)施。
另外，我們也給大家提供了一些黑盒監(jiān)控的實(shí)施經(jīng)驗(yàn)：
首先，應(yīng)該監(jiān)控哪些功能?建議將系統(tǒng)接入層的訪問日志，URL添加黑盒監(jiān)控。那TOP-9的URL是否一定需要監(jiān)控?URL是否一定不需要監(jiā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)
從用戶的角度看，Prometheus的整體架構(gòu)設(shè)計(jì)參考了Google BorgMon，系統(tǒng)具有高度的靈活性，圍繞其開放性現(xiàn)在也慢慢形成了一個(gè)生態(tài)系統(tǒng)。具體來(lái)說(shuō)，Prometheus 使用的是 Pull 模型，Prometheus Server 通過 HTTP 的 Pull 方式到各個(gè)目標(biāo)拉取監(jiān)控?cái)?shù)據(jù)。HTTP協(xié)議的支持能夠更加方便的進(jìn)行定制化開發(fā)，服務(wù)注冊(cè)、信息采集和數(shù)據(jù)展示均支持多種形式/開源軟件。
結(jié)合目前國(guó)內(nèi)正在興起的智能運(yùn)維，也許不久的將來(lái)，上面提到的監(jiā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ù)在各類異構(gòu)網(wǎng)絡(luò)環(huán)境下提供標(biāo)準(zhǔn)和統(tǒng)一的運(yùn)維支撐能力。
基于產(chǎn)品所處的發(fā)展階段，用戶規(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ī)制，并通過定期的破壞演練持續(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ā)生后有人處理并在規(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)的繁榮。
在監(jiān)控方向，Prometheus在未來(lái)一段時(shí)間后，也許會(huì)是一個(gè)很好的選擇。在Prometheus等工具解決了通用的監(jiān)控場(chǎng)景并標(biāo)準(zhǔn)化之后，在其上的各類應(yīng)用場(chǎng)景，如容量規(guī)劃，流量監(jiān)控，故障定位以及各種基于大數(shù)據(jù)和人工智能場(chǎng)景的落地等，就會(huì)出現(xiàn)百花齊放之勢(shì)。
【本文為51CTO專欄作者“京東云”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過作者微信公眾號(hào)JD-jcloud獲取授權(quán)】
