完美世界有声小说,完美世界前传下载

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

微服務(wù)架構(gòu)下的監(jiān)控需要注意哪些方面？

本期我們重點講述微服務(wù)架構(gòu)下的監(jiān)控

創(chuàng)新互聯(lián)建站于2013年創(chuàng)立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項目網(wǎng)站設(shè)計制作、成都做網(wǎng)站網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元東鄉(xiāng)做網(wǎng)站,已為上家服務(wù),為東鄉(xiāng)各地企業(yè)和個人服務(wù),聯(lián)系電話:18980820575

微服務(wù)架構(gòu)雖然誕生的時間并不長，卻因為適應(yīng)現(xiàn)今互聯(lián)網(wǎng)的高速發(fā)展和敏捷、DevOps等文化而受到很多企業(yè)的推崇。微服務(wù)架構(gòu)在帶來靈活性、擴展性、伸縮性以及高可用性等優(yōu)點的同時，其復雜性也給運維工作中最重要的監(jiān)控環(huán)節(jié)帶來了很大的挑戰(zhàn)：海量日志數(shù)據(jù)如何處理，服務(wù)如何追蹤，如何高效定位故障縮短故障時長……今天，我們就來談一談微服務(wù)架構(gòu)下的監(jiān)控應(yīng)該注意哪些方面。

微服務(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)復雜度的快速增長;
觀念的轉(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)控指標，聚合指標，報警閾值，報警依賴，報警接收人，策略級別，處理預案和備注說明也不完全相同;如此多的內(nèi)容，如何確保是否有效，是否生效，是否完整無遺漏。

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

通過變量的方式盡量減少人工輸入
通過監(jiān)控配置文件解析做一些可標準化的校驗
通過故障演練驗證報警是否符合預期

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

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

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

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

在微服務(wù)架構(gòu)下，監(jiān)控系統(tǒng)在報警時效性不可改變的前提下，采集的指標數(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)整使用頻率較低指標的采集周期;
通過批量寫入降低Hbase的寫入壓力;
通過寫入兩套Hbase避免數(shù)據(jù)丟失并做到故障后快速切換。

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

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

實時熱加載服務(wù)注冊信息;
對監(jiān)控配置的合規(guī)性進行強校驗;
增加實例數(shù)量的閾值保護;
支持配置的快速回滾。

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

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

基于報警接收人通過延時發(fā)送進行合并;
報警策略添加依賴關(guān)系;
優(yōu)先發(fā)送嚴重故障的報警短信;
增加多種報警通知方式如電話、IM等。

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

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

首先，所有系統(tǒng)和第三方依賴的核心功能必須添加黑盒監(jiān)控;
第二，所有模塊必須添加白盒監(jiān)控的四個黃金指標(飽和度，錯誤，流量和延時);
第三，所有的變更都需要進行采集，包括但不限于程序，配置，數(shù)據(jù)，網(wǎng)絡(luò)，硬件，操作系統(tǒng)以及各類基礎(chǔ)設(shè)施。

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

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

第二，應(yīng)該使用多少個樣本/節(jié)點對一個功能進行黑盒監(jiān)控?建議樣本應(yīng)該覆蓋到對應(yīng)模塊的所有實例，這樣也能發(fā)現(xiàn)由少數(shù)實例導致的小規(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 方式到各個目標拉取監(jiān)控數(shù)據(jù)。HTTP協(xié)議的支持能夠更加方便的進行定制化開發(fā)，服務(wù)注冊、信息采集和數(shù)據(jù)展示均支持多種形式/開源軟件。

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

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

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

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

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

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

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

總結(jié)

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

在監(jiān)控方向，Prometheus在未來一段時間后，也許會是一個很好的選擇。在Prometheus等工具解決了通用的監(jiān)控場景并標準化之后，在其上的各類應(yīng)用場景，如容量規(guī)劃，流量監(jiān)控，故障定位以及各種基于大數(shù)據(jù)和人工智能場景的落地等，就會出現(xiàn)百花齊放之勢。

【本文為專欄作者“京東云”的原創(chuàng)稿件，轉(zhuǎn)載請通過作者微信公眾號JD-jcloud獲取授權(quán)】

本文題目：微服務(wù)架構(gòu)下的監(jiān)控需要注意哪些方面？
新聞來源：http://www.fisionsoft.com.cn/article/cdheode.html

新聞中心

其他資訊