電商微服務(wù)實戰(zhàn)之服務(wù)監(jiān)控

監(jiān)控對象

一般可分為四類：

用戶端監(jiān)控

業(yè)務(wù)直接對用戶提供的功能的監(jiān)控。以知乎首頁Feed為例，它向用戶提供了聚合關(guān)注的所有人的動態(tài)并按時間順序瀏覽的功能，對首頁Feed功能的監(jiān)控就屬于用戶端監(jiān)控

接口監(jiān)控

業(yè)務(wù)提供的功能所依賴的具體RPC接口的監(jiān)控。微博首頁Feed例，該功能依賴于用戶關(guān)注了哪些人的關(guān)系服務(wù)，每個人發(fā)過哪些微博的微博列表服務(wù)，以及每條微博具體內(nèi)容是什么的內(nèi)容服務(wù)，對這幾個服務(wù)的調(diào)用情況的監(jiān)控就屬于接口監(jiān)控。

資源監(jiān)控

某接口依賴的資源的監(jiān)控。比如關(guān)系服務(wù)中的用戶關(guān)注了誰，使用Redis存儲的關(guān)注列表，對Redis監(jiān)控就屬資源監(jiān)控。

基礎(chǔ)監(jiān)控

對服務(wù)器本身的健康狀況的監(jiān)控。如CPU利用率、內(nèi)存使用量、I/O讀寫量、網(wǎng)卡帶寬等。

監(jiān)控指標(biāo)

請求量

請求量監(jiān)控分倆維度：

實時請求量

QPS（Queries Per Second）即每秒查詢次數(shù)，反映服務(wù)調(diào)用的實時變化

統(tǒng)計請求量

PV（Page View）即一段時間內(nèi)用戶訪問量。比如一天PV代表服務(wù)一天的請求量，常用來統(tǒng)計報表。

響應(yīng)時間

可用一段時間內(nèi)所有調(diào)用的平均耗時反映請求響應(yīng)時間。但只代表請求的平均快慢，有時更關(guān)心慢請求的數(shù)量。需把響應(yīng)時間劃分多區(qū)間，比如0～10ms、10ms～50ms、50ms～100ms、100ms～500ms、>500ms，>500ms區(qū)間內(nèi)請求數(shù)即代表慢請求量，正常情況下該區(qū)間內(nèi)請求數(shù)應(yīng)該接近0；出現(xiàn)問題時，區(qū)間內(nèi)請求數(shù)會大幅增加，可能平均耗時并不能反映變化。

還可以P90、P95、P99、P999角度來監(jiān)控請求的響應(yīng)時間，比如P99 = 500ms，意思是99%的請求響應(yīng)時間在500ms以內(nèi)，它代表了請求的服務(wù)質(zhì)量，即SLA。

錯誤率

一段時間內(nèi)調(diào)用失敗的次數(shù)占調(diào)用總次數(shù)比率，比如對于接口的錯誤率一般用接口返回錯誤碼為503的比率來表示。

監(jiān)控維度

全局維度

從整體角度監(jiān)控對象的的請求量、平均耗時以及錯誤率，全局維度的監(jiān)控一般是為了讓你對監(jiān)控對象的調(diào)用情況有個整體了解。

分機房維度

一般為了業(yè)務(wù)高可用，服務(wù)部署在不止一個機房，因不同機房地域不同，同一監(jiān)控對象的各種指標(biāo)可能會相差很大，需要深入機房內(nèi)部探查。

單機維度

即使在同一機房，由于采購年份和批次不同，不同機器上的同一監(jiān)控對象指標(biāo)也有很大差異。一般新采購機器通常由于成本更低，配置也更高，在同等請求量的情況下，可能表現(xiàn)出較大的性能差異，因此也需要從單機維度去監(jiān)控同一個對象。

時間維度

同一監(jiān)控對象，在每天同一時刻各種指標(biāo)通常也不一樣，要么由業(yè)務(wù)變更導(dǎo)致，要么運營活動導(dǎo)致。為了解監(jiān)控對象各種指標(biāo)的變化，通常需要與一天前、一周前、一個月前，甚至三個月前對比。

核心維度

業(yè)務(wù)上一般會依據(jù)重要性程度對監(jiān)控對象進行分級，最簡單的是分成核心業(yè)務(wù)和非核心業(yè)務(wù)。核心業(yè)務(wù)和非核心業(yè)務(wù)在部署上必須隔離，分開監(jiān)控，這樣才能對核心業(yè)務(wù)做重點保障。

如何搭建監(jiān)控系統(tǒng)，來完成上面這些監(jiān)控功能呢？

監(jiān)控系統(tǒng)原理

監(jiān)控系統(tǒng)主要包括四個環(huán)節(jié)：

數(shù)據(jù)采集

要監(jiān)控服務(wù)調(diào)用，首先要能收集到每次調(diào)用的詳細(xì)信息，包括調(diào)用響應(yīng)時間、調(diào)用是否成功、調(diào)用的發(fā)起者和接收者

數(shù)據(jù)傳輸

把數(shù)據(jù)通過傳輸給數(shù)據(jù)處理中心

數(shù)據(jù)處理

數(shù)據(jù)處理中心再按服務(wù)維度進行聚合，計算不同服務(wù)請求量、響應(yīng)時間以及錯誤率等信息并存儲

數(shù)據(jù)展示

最后通過接口或者Dashboard的形式對外展示服務(wù)的調(diào)用情況

1 數(shù)據(jù)采集

有如下方式：

服務(wù)主動上報

通過在業(yè)務(wù)代碼或者服務(wù)框架里加入數(shù)據(jù)收集代碼邏輯，在每次服務(wù)調(diào)用完成后，主動上報服務(wù)調(diào)用信息。

代理收集

通過服務(wù)調(diào)用后把調(diào)用的詳細(xì)信息記錄到本地日志文件，再通過代理去解析本地日志文件，最后再上報服務(wù)的調(diào)用信息。

無論哪種，首先要考慮采樣率，即采集數(shù)據(jù)的頻率。采樣率越高，監(jiān)控實時性就越高，精確度越高。但采樣對系統(tǒng)性能也會有影響，尤其是采集后的數(shù)據(jù)需寫到本地磁盤時，過高采樣率會導(dǎo)致寫入磁盤的I/O過高，影響正常服務(wù)調(diào)用。

所以設(shè)置合理采用率是關(guān)鍵，最好可動態(tài)控制采樣率

系統(tǒng)較閑時，加大采樣率，追求監(jiān)控實時性與精確度

系統(tǒng)負(fù)載較高時，減小采樣率，追求監(jiān)控的可用性與系統(tǒng)的穩(wěn)定性

數(shù)據(jù)傳輸

常用方式如下：

UDP傳輸

數(shù)據(jù)處理單元提供服務(wù)器的請求地址，數(shù)據(jù)采集后通過UDP協(xié)議與服務(wù)器建立連接，然后把數(shù)據(jù)發(fā)送過去。

Kafka傳輸

數(shù)據(jù)采集后發(fā)送到指定的Topic，然后數(shù)據(jù)處理單元再訂閱對應(yīng)的Topic，即可從Kafka消息隊列中讀取到對應(yīng)的數(shù)據(jù)。

無論哪種，數(shù)據(jù)格式都十分重要，尤其是對帶寬敏感以及解析性能要求比較高的場景，一般數(shù)據(jù)傳輸時采用的數(shù)據(jù)格式有兩種：

二進制協(xié)議，最常用的就是PB對象，它的優(yōu)點是高壓縮比和高性能，可以減少傳輸帶寬并且序列化和反序列化效率特別高。

文本協(xié)議，最常用的就是JSON字符串，它的優(yōu)點是可讀性好，但相比于PB對象，傳輸占用帶寬高，并且解析性能也要差一些。

數(shù)據(jù)處理

聚合并存儲收集來的原始數(shù)據(jù)。

數(shù)據(jù)聚合通常有兩個維度：

接口維度聚合

把實時收到的數(shù)據(jù)按接口名維度實時聚合在一起，得到每個接口的實時請求量、平均耗時等信息。

機器維度聚合

把實時收到的數(shù)據(jù)按照調(diào)用的節(jié)點維度聚合在一起，這樣就可以從單機維度去查看每個接口的實時請求量、平均耗時等信息。

聚合后數(shù)據(jù)需持久化到DB，所選用DB一般兩種：

索引數(shù)據(jù)庫

e.g. Elasticsearch，以倒排索引的數(shù)據(jù)結(jié)構(gòu)存儲，需要查詢的時候，根據(jù)索引來查詢

時序數(shù)據(jù)庫

e.g. OpenTSDB，以時序序列數(shù)據(jù)方式存儲，查詢時按照時序如1min、5min等維度來查詢。

數(shù)據(jù)展示

把處理后的數(shù)據(jù)以Dashboard方式展示給用戶。

數(shù)據(jù)展示有多種方式，比如曲線圖、餅狀圖、格子圖。

曲線圖

一般是用來監(jiān)控變化趨勢的，比如下面的曲線圖展示了監(jiān)控對象隨著時間推移的變化趨勢，可以看出來這段時間內(nèi)變化比較小，曲線也比較平穩(wěn)。

餅狀圖

一般是用來監(jiān)控占比分布的，比如下面這張餅圖展示了使用不同的手機網(wǎng)絡(luò)占比情況，可見Wi-Fi和4G的占比明顯要高于3G和2G。

格子圖

主要做一些細(xì)粒度的監(jiān)控，比如下面這張格子圖代表了不同的機器的接口調(diào)用請求量和耗時情況，展示結(jié)果一目了然。

總結(jié)

服務(wù)監(jiān)控在微服務(wù)改造過程中十分重要，沒有強大監(jiān)控能力，就無法掌控各個不同服務(wù)的情況，在遇到調(diào)用失敗時，如果不能快速發(fā)現(xiàn)系統(tǒng)的問題，業(yè)務(wù)就成了災(zāi)難。

參考

如何監(jiān)控微服務(wù)調(diào)用

微服務(wù) 自建電商

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。