在微服務架構的系列文章中，前面已經通過文章分別介紹過了微服務的「服務註冊 」、「服務閘道器 」、「配置中心 」，今天這篇文章我們繼續來聊一聊另外一個重要模組：「 監控系統 」。
因為在微服務的架構下，我們對服務進行了拆分，所以使用者的每次請求不再是由某一個服務獨立完成了，而是變成了多個服務一起配合完成。這種情況下，一旦請求出現異常，我們必須得知道是在哪個服務環節出了故障，就需要對每一個服務，以及各個指標都進行全面的監控。
一、什麼是「 監控系統 」？
在微服務架構中，監控系統按照原理和作用大致可以分為三類（並非嚴格分類，僅從日常使用角度來看）：
-
日誌類（Log）
-
呼叫鏈類（Tracing）
-
度量類（Metrics）
下面來分別對這三種常見的監控模式進行說明：
-
日誌類（Log）
日誌類比較常見，我們的框架程式碼、系統環境、以及業務邏輯中一般都會產出一些日誌，這些日誌我們通常把它記錄後統一收集起來，方便在需要的時候進行查詢。
日誌類記錄的資訊一般是一些事件、非結構化的一些文字內容。日誌的輸出和處理的解決方案比較多，大家熟知的有 ELK Stack 方案（Elasticseach + Logstash + Kibana），如圖：
使用Beats（可選）在每臺伺服器上安裝後，作為日誌客戶端收集器，然後通過Logstash進行統一的日誌收集、解析、過濾等處理，再將資料傳送給Elasticsearch中進行儲存分析，最後使用Kibana來進行資料的展示。當然還可以升級方案為：
這些方案都比較成熟，搭建起來也比較簡單，除了用作監控系統以外，還可以作為日誌查詢系統使用，非常適用於做分析、以及問題除錯使用。 -
呼叫鏈類（Tracing）
呼叫鏈類監控主要是指記錄一個請求的全部流程。一個請求從開始進入，在微服務中呼叫不同的服務節點後，再返回給客戶端，在這個過程中通過呼叫鏈引數來追尋全鏈路行為。通過這個方式可以很方便的知道請求在哪個環節出了故障，系統的瓶頸在哪兒。
這一類的監控一般採用 CAT 工具 來完成，一般在大中型專案較多用到，因為搭建起來有一定的成本。後面會有單獨文章來講解這個呼叫鏈監控系統。
-
度量類（Metrics）
度量類主要採用 時序資料庫 的解決方案。它是以事件發生時間以及當前數值的角度來記錄的監控資訊，是可以聚合運算的，用於檢視一些指標資料和指標趨勢。所以這類監控主要不是用來查問題的，主要是用來看趨勢的。
Metrics一般有5種基本的度量型別：Gauges（度量）、Counters（計數器）、 Histograms（直方圖）、 Meters（TPS計算器）、Timers（計時器）。
基於時間序列資料庫的監控系統是非常適合做監控告警使用的，所以現在也比較流行這個方案，如果我們要搭建一套新的監控系統，我也建議參考這類方案進行。
因此本文接下來也會重點以時間序列資料庫的監控系統為主角來描述。
二、「 監控系統 」關注的物件和指標都是什麼？
一般我們做「監控系統」都是需要做分層式監控的，也就是說將我們要監控的物件進行分層，一般主要分為：
-
系統層：系統層主要是指CPU、磁碟、記憶體、網路等伺服器層面的監控，這些一般也是運維同學比較關注的物件。
-
應用層：應用層指的是服務角度的監控，比如介面、框架、某個服務的健康狀態等，一般是服務開發或框架開發人員關注的物件。
-
使用者層：這一層主要是與使用者、與業務相關的一些監控，屬於功能層面的，大多數是專案經理或產品經理會比較關注的物件。
知道了監控的分層後，我們再來看一下監控的指標一般有哪些：
-
延遲時間：主要是響應一個請求所消耗的延遲，比如某介面的HTTP請求平均響應時間為100ms。
-
請求量：是指系統的容量吞吐能力，例如每秒處理多少次請求（QPS）作為指標。
-
錯誤率：主要是用來監控錯誤發生的比例，比如將某介面一段時間內呼叫時失敗的比例作為指標。
三、基於時序資料庫的「 監控系統 」有哪些？
下面介紹幾款目前業內比較流行的基於時間序列資料庫的開源監控方案：
-
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來展示。
-
OpenTSDB
OpenTSDB是在2010年開源的一款分散式時序資料庫，當然其主要用於監控方案中。
OpenTSDB採用的是Hbase的分散式儲存，它獲取資料的模式與Prometheus不同，它採用的是推模式（Push）。
在展示層，OpenTSDB自帶有WebUI檢視，也可以與Grafana很好的整合，提供豐富的展示介面。
但OpenTSDB並沒有自帶預警模組，需要自己去開發或者與第三方元件結合使用。
可以通過下圖來了解一下OpenTSDB的架構：
-
InfluxDB
InfluxDB是在2013年開源的一款時序資料庫，在這裡我們主要還是用於做監控系統方案。它收集資料也是採用推模式（Push）。在展示層，InfluxDB也是自帶WebUI，也可以與Grafana整合。
以上，就是對微服務架構中「 監控系統」的一些思考。
碼字不易啊，喜歡的話不妨轉發朋友，或點選文章右下角的“在看”吧。?
本文原創釋出於微信公眾號「 不止思考 」，歡迎關注。涉及 思維認知、個人成長、架構、大資料、Web技術 等。
