微服務(wù)框架之監(jiān)控系統(tǒng)

隋中昱含 李迎接 姚翔宇 查蘊(yùn)初

【摘 要】微服務(wù)框架是每個(gè)IT認(rèn)識(shí)應(yīng)當(dāng)熟練掌握的，它的作用體現(xiàn)在方方面面，能夠熟練的運(yùn)用并且知曉其中的原理、作用結(jié)果，能夠幫助我們更好的了解計(jì)算機(jī)的實(shí)時(shí)狀態(tài)。所以這篇文章對(duì)微服務(wù)框架之一的監(jiān)控系統(tǒng)做一些簡(jiǎn)單的介紹，幫助大家了解一些常見(jiàn)的監(jiān)控適用范圍。

【關(guān)鍵詞】微服務(wù)；監(jiān)控；系統(tǒng)框架

在微服務(wù)架構(gòu)的系列文章中，前面已經(jīng)通過(guò)文章分別介紹過(guò)了微服務(wù)的「服務(wù)注冊(cè)」、「服務(wù)網(wǎng)關(guān)」、「配置中心」，今天這篇文章我們繼續(xù)來(lái)聊一聊另外一個(gè)重要模塊：「監(jiān)控系統(tǒng)」。

因?yàn)樵谖⒎?wù)的架構(gòu)下，我們對(duì)服務(wù)進(jìn)行了拆分，所以用戶的每次請(qǐng)求不再是由某一個(gè)服務(wù)獨(dú)立完成了，而是變成了多個(gè)服務(wù)一起配合完成。這種情況下，一旦請(qǐng)求出現(xiàn)異常，我們必須得知道是在哪個(gè)服務(wù)環(huán)節(jié)出了故障，就需要對(duì)每一個(gè)服務(wù)，以及各個(gè)指標(biāo)都進(jìn)行全面的監(jiān)控。

一、什么是「監(jiān)控系統(tǒng)」？

在微服務(wù)架構(gòu)中，監(jiān)控系統(tǒng)按照原理和作用大致可以分為三類（并非嚴(yán)格分類，僅從日常使用角度來(lái)看）：

日志類（Log）、調(diào)用鏈類（Tracing）、度量類（Metrics）

下面來(lái)分別對(duì)這三種常見(jiàn)的監(jiān)控模式進(jìn)行說(shuō)明：

日志類（Log）

日志類比較常見(jiàn)，我們的框架代碼、系統(tǒng)環(huán)境、以及業(yè)務(wù)邏輯中一般都會(huì)產(chǎn)出一些日志，這些日志我們通常把它記錄后統(tǒng)一收集起來(lái)，方便在需要的時(shí)候進(jìn)行查詢。

日志類記錄的信息一般是一些事件、非結(jié)構(gòu)化的一些文本內(nèi)容。日志的輸出和處理的解決方案比較多，大家熟知的有 ELK Stack 方案（Elasticseach + Logstash + Kibana），如圖：

使用Beats（可選）在每臺(tái)服務(wù)器上安裝后，作為日志客戶端收集器，然后通過(guò)Logstash進(jìn)行統(tǒng)一的日志收集、解析、過(guò)濾等處理，再將數(shù)據(jù)發(fā)送給Elasticsearch中進(jìn)行存儲(chǔ)分析，最后使用Kibana來(lái)進(jìn)行數(shù)據(jù)的展示。

調(diào)用鏈類（Tracing）

調(diào)用鏈類監(jiān)控主要是指記錄一個(gè)請(qǐng)求的全部流程。一個(gè)請(qǐng)求從開(kāi)始進(jìn)入，在微服務(wù)中調(diào)用不同的服務(wù)節(jié)點(diǎn)后，再返回給客戶端，在這個(gè)過(guò)程中通過(guò)調(diào)用鏈參數(shù)來(lái)追尋全鏈路行為。通過(guò)這個(gè)方式可以很方便的知道請(qǐng)求在哪個(gè)環(huán)節(jié)出了故障，系統(tǒng)的瓶頸在哪兒。

這一類的監(jiān)控一般采用CAT工具來(lái)完成，一般在大中型項(xiàng)目較多用到，因?yàn)榇罱ㄆ饋?lái)有一定的成本。后面會(huì)有單獨(dú)文章來(lái)講解這個(gè)調(diào)用鏈監(jiān)控系統(tǒng)。

度量類（Metrics）

度量類主要采用時(shí)序數(shù)據(jù)庫(kù)的解決方案。它是以事件發(fā)生時(shí)間以及當(dāng)前數(shù)值的角度來(lái)記錄的監(jiān)控信息，是可以聚合運(yùn)算的，用于查看一些指標(biāo)數(shù)據(jù)和指標(biāo)趨勢(shì)。所以這類監(jiān)控主要不是用來(lái)查問(wèn)題的，主要是用來(lái)看趨勢(shì)的。

Metrics一般有5種基本的度量類型：Gauges（度量）、Counters（計(jì)數(shù)器）、Histograms（直方圖）、Meters（TPS計(jì)算器）、Timers（計(jì)時(shí)器）。

基于時(shí)間序列數(shù)據(jù)庫(kù)的監(jiān)控系統(tǒng)是非常適合做監(jiān)控告警使用的，所以現(xiàn)在也比較流行這個(gè)方案，如果我們要搭建一套新的監(jiān)控系統(tǒng)，我也建議參考這類方案進(jìn)行。

因此本文接下來(lái)也會(huì)重點(diǎn)以時(shí)間序列數(shù)據(jù)庫(kù)的監(jiān)控系統(tǒng)為主角來(lái)描述。

二、「監(jiān)控系統(tǒng)」關(guān)注的對(duì)象和指標(biāo)都是什么？

一般我們做「監(jiān)控系統(tǒng)」都是需要做分層式監(jiān)控的，也就是說(shuō)將我們要監(jiān)控的對(duì)象進(jìn)行分層，一般主要分為：

系統(tǒng)層：系統(tǒng)層主要是指CPU、磁盤(pán)、內(nèi)存、網(wǎng)絡(luò)等服務(wù)器層面的監(jiān)控，這些一般也是運(yùn)維同學(xué)比較關(guān)注的對(duì)象。

應(yīng)用層：應(yīng)用層指的是服務(wù)角度的監(jiān)控，比如接口、框架、某個(gè)服務(wù)的健康狀態(tài)等，一般是服務(wù)開(kāi)發(fā)或框架開(kāi)發(fā)人員關(guān)注的對(duì)象。

用戶層：這一層主要是與用戶、與業(yè)務(wù)相關(guān)的一些監(jiān)控，屬于功能層面的，大多數(shù)是項(xiàng)目經(jīng)理或產(chǎn)品經(jīng)理會(huì)比較關(guān)注的對(duì)象。

知道了監(jiān)控的分層后，我們?cè)賮?lái)看一下監(jiān)控的指標(biāo)一般有哪些：

延遲時(shí)間：主要是響應(yīng)一個(gè)請(qǐng)求所消耗的延遲，比如某接口的HTTP請(qǐng)求平均響應(yīng)時(shí)間為100ms。

請(qǐng)求量：是指系統(tǒng)的容量吞吐能力，例如每秒處理多少次請(qǐng)求（QPS）作為指標(biāo)。

錯(cuò)誤率：主要是用來(lái)監(jiān)控錯(cuò)誤發(fā)生的比例，比如將某接口一段時(shí)間內(nèi)調(diào)用時(shí)失敗的比例作為指標(biāo)。

三、基于時(shí)序數(shù)據(jù)庫(kù)的「監(jiān)控系統(tǒng)」有哪些？

下面介紹幾款目前業(yè)內(nèi)比較流行的基于時(shí)間序列數(shù)據(jù)庫(kù)的開(kāi)源監(jiān)控方案：

Prometheus：Promethes是一款2012年開(kāi)源的監(jiān)控框架，其本質(zhì)是時(shí)間序列數(shù)據(jù)庫(kù)，由Google前員工所開(kāi)發(fā)。Promethes采用拉的模式（Pull）從應(yīng)用中拉取數(shù)據(jù)，并還支持Alert模塊可以實(shí)現(xiàn)監(jiān)控預(yù)警。它的性能非常強(qiáng)勁，單機(jī)可以消費(fèi)百萬(wàn)級(jí)時(shí)間序列。

需要拉取的數(shù)據(jù)既可以采用靜態(tài)方式配置在Prometheus Server中，也可以采用服務(wù)發(fā)現(xiàn)的方式。

PromQL：是Prometheus自帶的查詢語(yǔ)法，通過(guò)編寫(xiě)PromQL語(yǔ)句可以查詢Prometheus里面的數(shù)據(jù)。

Alertmanager：是用于數(shù)據(jù)的預(yù)警模塊，支持通過(guò)多種方式去發(fā)送預(yù)警。

WebUI：是用來(lái)展示數(shù)據(jù)和圖形的，但是一般大多數(shù)是與Grafana結(jié)合，采用Grafana來(lái)展示。

OpenTSDB：OpenTSDB是在2010年開(kāi)源的一款分布式時(shí)序數(shù)據(jù)庫(kù)，當(dāng)然其主要用于監(jiān)控方案中。OpenTSDB采用的是Hbase的分布式存儲(chǔ)，它獲取數(shù)據(jù)的模式與Prometheus不同，它采用的是推模式（Push）。在展示層，OpenTSDB自帶有WebUI視圖，也可以與Grafana很好的集成，提供豐富的展示界面。但OpenTSDB并沒(méi)有自帶預(yù)警模塊，需要自己去開(kāi)發(fā)或者與第三方組件結(jié)合使用。

InfluxDB：InfluxDB是在2013年開(kāi)源的一款時(shí)序數(shù)據(jù)庫(kù)，在這里我們主要還是用于做監(jiān)控系統(tǒng)方案。它收集數(shù)據(jù)也是采用推模式（Push）。在展示層，InfluxDB也是自帶WebUI，也可以與Grafana集成。

【參考文獻(xiàn)】

[1]鄭錦男，李舒涵，許宏科.微服務(wù)框架下的交通信息化架構(gòu)[J].信息技術(shù)，2019，43（01）：157-162.

[2]辛園園，鈕俊，謝志軍，張開(kāi)樂(lè)，毛昕怡.微服務(wù)體系結(jié)構(gòu)實(shí)現(xiàn)框架綜述[J].計(jì)算機(jī)工程與應(yīng)用，2018，54（19）：10-17.

[3]王志勃，王麒森，畢艷茹.互聯(lián)網(wǎng)環(huán)境下微服務(wù)框架分析與研究[J].信息與電腦（理論版），2017（22）：23-25.

[4]張晶，黃小鋒，李春陽(yáng).微服務(wù)框架的設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)系統(tǒng)應(yīng)用，2017，26（06）：259-262.