-     前言     -

“監控”是微服務治理的一個重要環節，監控系統的完善程度直接影響到我們微服務質量的好壞，我們的微服務在線上執行時，有沒有一套完善的監控體系能去了解到它的健康情況，這對整個系統的可靠性和穩定性非常重要。

-    微服務監控體系的層級架構    -

1、五個層級的監控

一個比較完善的微服務監控體系需要涉及到哪些層級？如下圖所示，大致可以劃分為五個層級的監控：

2、最底層基礎設施監控

這層一般由運維人員負責，涉及到的方面比較接近硬體體系，例如網路，交換機，路由器等低層裝置，這些裝置的可靠性穩定性就直接影響到上層服務應用的穩定性，所以需要對網路的流量，丟包情況、錯包情況，連線數等等這些基礎設施的核心指標進行監控。

3、系統層監控

這層涵蓋了物理機、虛擬機器、作業系統等，這些都是屬於系統級別監控的方面，主要對幾個核心指標進行監控，如cpu使用率、記憶體佔用率，磁碟IO和網路頻寬情況。

4、應用層監控

這層涉及到方面和服務緊密相關，例如對url訪問的效能，訪問的呼叫數，訪問的延遲，還有對服務提供效能進行監控，服務的錯誤率等，同時對sql也需要進行監控，檢視是否有慢sql。對於cache來說，需要監控快取的命中率和效能，每個服務的響應時間和qps等等。

5、業務監控

業務監控具體指什麼？舉個例子，比如說一個典型的交易網站，需要關注它的使用者登入情況、註冊情況、下單情況、支付情況等等，這些直接影響到實際觸發的業務交易情況，這層監控可以提供給運營和公司高管們，提供他們需要關注的資料，直接以資料支撐公司在戰略層面的決策和方向。

6、端使用者體驗監控

一個應用程式可能透過app、h5、pc端的方式交付到使用者的手上，使用者透過瀏覽器，客戶端開啟連到我們的服務，那麼在使用者端，使用者的體驗是怎麼樣？使用者端的效能是怎麼樣？以及有沒有產生錯誤等等……

這些資訊都需要進行監控並記錄下來，如果沒有監控，有可能因為某些BUG或者效能問題，造成使用者體驗非常差，而我們並沒有感知。

其中包括監控使用者端的使用效能、返回碼，在哪些城市地區，他們的使用情況是怎麼樣，還有運營商的情況，包括三大運營商不同使用者的連線情況。我們需要進一步知道，是否有哪些渠道哪些使用者接入的時候存在著問題，我們還需要知道客戶端使用的作業系統瀏覽器的版本。

簡單來說，這就是我們體系化的監控分層，每一個層級都非常重要。一般情況下，當一個問題出現時，較大機率會先暴露在使用者端或業務層，比如說，我們的訂單量下降了，業務人員和開發人員會先從上到下去逐層檢查是在哪裡出現了問題，先確定是否哪個介面呼叫比較慢，哪個服務調用出現延時，再看是否哪個機器負載過高了，然後再進一步往下一個層去看，是否是網路呼叫不穩定導致。所以，一個好的監控體系，在每個層級都非常重要。

-    微服務監控的要點  -

1、五個監控要點

上文講解的是從層級方面進行監控，接下來，我們來看看哪些要點可以進行監控：

簡單來說，可以分為以下五個點：

1、日誌監控

2、Metrics監控

3、呼叫鏈監控

4、報警系統

5、健康檢查

2、典型主流的監控架構

在微服務執行的體系下，我們一般把監控的agent分散到各個服務身邊，agent分別是收集機器和服務的metrics，傳送到後臺監控系統，一般來說，我們的服務量非常大，在收集的過程中，會加入佇列。一般來說用kafka等訊息佇列有個好處，兩邊可以進行解耦，可以起到龐大的日誌進行一個快取的地帶，並且可以做到高可用，保證訊息不會丟失。

日誌收集目前比較流行的是ELK的一套解決方案（Elasticsearch，Logstash，Kibana），Elasticsearch 分散式搜尋引擎，Logstash 是一個日誌收集的agent，Kibana 是一個查詢的日誌介面。

metrice會採用一個時間序列的資料庫，influxDB是最近比較主流時間資料庫。

微服務的agent例如springboot也提供了健康檢查的端點，可以檢查cpu使用情況、記憶體使用情況、jvm使用情況，這些需要一個健康檢查機制，能夠定期對服務的健康和機器的健康進行check，比較常見的是nagios、zabbix等，這些開源平臺能夠定期去檢查到各個微服務的檢查程式並能夠進行告警給相關人員，在服務未崩潰之前就可以進行提前的預先接入。