微服務架構之「 監控系統 」

在微服務架構的系列文章中，前面已經經過文章分別介紹過了微服務的「服務註冊 」、「服務網關 」、「配置中心 」，今天這篇文章咱們繼續來聊一聊另一個重要模塊：「 監控系統 」。

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

1、什麼是「 監控系統 」？

在微服務架構中，監控系統按照原理和做用大體能夠分爲三類（並不是嚴格分類，僅從平常使用角度來看）：

• 日誌類（Log）

• 調用鏈類（Tracing）

• 度量類（Metrics）

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

1. 日誌類（Log）

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

   日誌類記錄的信息通常是一些事件、非結構化的一些文本內容。日誌的輸出和處理的解決方案比較多，你們熟知的有 ELK Stack 方案（Elasticseach + Logstash + Kibana），如圖：

   使用Beats（可選）在每臺服務器上安裝後，做爲日誌客戶端收集器，而後經過Logstash進行統一的日誌收集、解析、過濾等處理，再將數據發送給Elasticsearch中進行存儲分析，最後使用Kibana來進行數據的展現。

   固然還能夠升級方案爲：

   這些方案都比較成熟，搭建起來也比較簡單，除了用做監控系統之外，還能夠做爲日誌查詢系統使用，很是適用於作分析、以及問題調試使用。

2. 調用鏈類（Tracing）

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

   這一類的監控通常採用 CAT 工具 來完成，通常在大中型項目較多用到，由於搭建起來有必定的成本。後面會有單獨文章來說解這個調用鏈監控系統。

3. 度量類（Metrics）

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

   Metrics通常有5種基本的度量類型：Gauges（度量）、Counters（計數器）、 Histograms（直方圖）、 Meters（TPS計算器）、Timers（計時器）。

   基於時間序列數據庫的監控系統是很是適合作監控告警使用的，因此如今也比較流行這個方案，若是咱們要搭建一套新的監控系統，我也建議參考這類方案進行。

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

2、「 監控系統 」關注的對象和指標都是什麼？

通常咱們作「監控系統」都是須要作分層式監控的，也就是說將咱們要監控的對象進行分層，通常主要分爲：

1. 系統層：系統層主要是指CPU、磁盤、內存、網絡等服務器層面的監控，這些通常也是運維同窗比較關注的對象。

2. 應用層：應用層指的是服務角度的監控，好比接口、框架、某個服務的健康狀態等，通常是服務開發或框架開發人員關注的對象。

3. 用戶層：這一層主要是與用戶、與業務相關的一些監控，屬於功能層面的，大多數是項目經理或產品經理會比較關注的對象。

知道了監控的分層後，咱們再來看一下監控的指標通常有哪些：

1. 延遲時間：主要是響應一個請求所消耗的延遲，好比某接口的HTTP請求平均響應時間爲100ms。

2. 請求量：是指系統的容量吞吐能力，例如每秒處理多少次請求（QPS）做爲指標。

3. 錯誤率：主要是用來監控錯誤發生的比例，好比將某接口一段時間內調用時失敗的比例做爲指標。

3、基於時序數據庫的「 監控系統 」有哪些？

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

• 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技術 等。