在微服務架構下，我們對服務進行了拆分，所以用戶的每次請求不再是由某一個服務獨立完成了，而是變成了多個服務一起配合完成。這種情況下，一旦請求出現異常，我們必須得知道是在哪個服務環節出了故障，就需要對每一個服務，以及各個指標都進行全面的監控。

[[277024]]

一、什么是「 監控系統 」?

在微服務架構中，監控系統按照原理和作用大致可以分為三類(并非嚴格分類，僅從日常使用角度來看)：

• 日志類(Log);
• 調用鏈類(Tracing);
• 度量類(Metrics)。

下面來分別對這三種常見的監控模式進行說明。

1、日志類

日志類比較常見，我們的框架代碼、系統環境，以及業務邏輯中一般都會產出一些日志，這些日志我們通常把它記錄后統一收集起來，方便在需要的時候進行查詢。

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

使用Beats(可選)在每臺服務器上安裝后，作為日志客戶端收集器，然后通過Logstash進行統一的日志收集、解析、過濾等處理，再將數據發送給Elasticsearch中進行存儲分析，最后使用Kibana來進行數據的展示。

當然還可以升級方案為：

這些方案都比較成熟，搭建起來也比較簡單，除了用作監控系統以外，還可以作為日志查詢系統使用，非常適用于做分析、以及問題調試使用。

2、調用鏈類(Tracing)

調用鏈類監控主要是指記錄一個請求的全部流程。一個請求從開始進入，在微服務中調用不同的服務節點后，再返回給客戶端，在這個過程中通過調用鏈參數來追尋全鏈路行為。通過這個方式可以很方便的知道請求在哪個環節出了故障，系統的瓶頸在哪兒。

這一類的監控一般采用CAT工具 來完成，一般在大中型項目較多用到，因為搭建起來有一定的成本。后面會有單獨文章來講解這個調用鏈監控系統。

這也是簡單的容錯方式。就是指在服務之間調用時，設置一個主動超時時間，超過了這個時間閾值后，如果“被依賴的服務”還沒有返回數據的話，“調用者”就主動放棄，防止因“被依賴的服務”的故障所影響。

3、度量類(Metrics)

度量類主要采用時序數據庫的解決方案。它是以事件發生時間以及當前數值的角度來記錄的監控信息，是可以聚合運算的，用于查看一些指標數據和指標趨勢。所以這類監控主要不是用來查問題的，主要是用來看趨勢的。

Metrics一般有5種基本的度量類型：

• Gauges(度量);
• Counters(計數器);
• Histograms(直方圖);
• Meters(TPS計算器);
• Timers(計時器)。

基于時間序列數據庫的監控系統是非常適合做監控告警使用的，所以現在也比較流行這個方案，如果我們要搭建一套新的監控系統，我也建議參考這類方案進行。

因此本文接下來也會重點以時間序列數據庫的監控系統為主角來描述。

二、「 監控系統 」關注的對象和指標都是什么?

一般我們做「監控系統」都是需要做分層式監控的，也就是說將我們要監控的對象進行分層，一般主要分為：

• 系統層：系統層主要是指CPU、磁盤、內存、網絡等服務器層面的監控，這些一般也是運維同學比較關注的對象;
• 應用層：應用層指的是服務角度的監控，比如接口、框架、某個服務的健康狀態等，一般是服務開發或框架開發人員關注的對象;
• 用戶層：這一層主要是與用戶、與業務相關的一些監控，屬于功能層面的，大多數是項目經理或產品經理會比較關注的對象。

知道了監控的分層后，我們再來看一下監控的指標一般有哪些：

• 延遲時間：主要是響應一個請求所消耗的延遲，比如某接口的HTTP請求平均響應時間為100ms;
• 請求量：是指系統的容量吞吐能力，例如每秒處理多少次請求(QPS)作為指標;
• 錯誤率：主要是用來監控錯誤發生的比例，比如將某接口一段時間內調用時失敗的比例作為指標。

三、基于時序數據庫的「 監控系統 」有哪些?

下面介紹幾款目前業內比較流行的基于時間序列數據庫的開源監控方案。

1、Prometheus

Promethes是一款2012年開源的監控框架，其本質是時間序列數據庫，由Google前員工所開發。

Promethes采用拉的模式(Pull)從應用中拉取數據，并還支持Alert模塊可以實現監控預警。它的性能非常強勁，單機可以消費百萬級時間序列。

架構如下：

從看圖的左下角可以看到，Prometheus可以通過在應用里進行埋點后Pull到Prometheus Server里，如果應用不支持埋點，也可以采用exporter方式進行數據采集。

從圖的左上角可以看到，對于一些定時任務模塊，因為是周期性運行的，所以采用拉的方式無法獲取數據，那么Prometheus也提供了一種推數據的方式，但是并不是推送到Prometheus Server中，而是中間搭建一個Pushgateway，定時任務模塊將metrics信息推送到這個Pushgateway中，然后Prometheus Server再依然采用拉的方式從Pushgateway中獲取數據。

需要拉取的數據既可以采用靜態方式配置在Prometheus Server中，也可以采用服務發現的方式(即圖的中上方Service discovery所示)。

PromQL：是Prometheus自帶的查詢語法，通過編寫PromQL語句可以查詢Prometheus里面的數據。

Alertmanager：是用于數據的預警模塊，支持通過多種方式去發送預警。

WebUI：是用來展示數據和圖形的，但是一般大多數是與Grafana結合，采用Grafana來展示。

2、OpenTSDB

OpenTSDB是在2010年開源的一款分布式時序數據庫，當然其主要用于監控方案中。

OpenTSDB采用的是HBase的分布式存儲，它獲取數據的模式與Prometheus不同，采用的是推模式(Push)。

在展示層，OpenTSDB自帶有WebUI視圖，也可以與Grafana很好的集成，提供豐富的展示界面。

但OpenTSDB并沒有自帶預警模塊，需要自己去開發或者與第三方組件結合使用。

可以通過下圖來了解一下OpenTSDB的架構：

3、InfluxDB

InfluxDB是在2013年開源的一款時序數據庫，在這里我們主要還是用于做監控系統方案。它收集數據也是采用推模式(Push)。在展示層，InfluxDB也是自帶WebUI，也可以與Grafana集成。

以上，就是我對微服務架構中「 監控系統」的一些思考。