(4)分散式系統關鍵技術：全棧監控

一、監控系統需要完成的功能為：

全棧監控；

關聯分析；

跨系統呼叫的串聯；

實時報警和自動處置；

系統效能分析。

多層體系的監控

二、全棧監控（就是三層監控）

基礎層：CPU、記憶體、網路吞吐、硬碟 I/O、硬碟使用等。

中間層：Nginx、Redis、ActiveMQ、Kafka、MySQL、Tomcat等。

應用層：HTTP 訪問的吞吐量、響應時間、返回碼，呼叫鏈路分析，效能瓶頸，還包括使用者端的監控。

監控的標準化：

(1)日誌資料結構化；

(2)監控資料格式標準化；

(3)統一的監控平臺；

(4)統一的日誌分析。

三、什麼才是好的監控系統

1.監控做不好，它們主要有兩個很大的問題。

監控資料是隔離。因為公司分工的問題，開發、應用運維、系統運維，各管各的，所以很多公司的監控系統也是各是各的，完全串不起來。

監控的資料項太多。資訊太多等於沒有資訊

2.好的監控系統應該有以下幾個特徵：

（1）關注於整體應用的 SLA（Service-Level Agreement服務等級協議）。主要從為使用者服務的 API 來監控整個系統。

（2）關聯指標聚合。 把有關聯的系統及其指標聚合展示。主要是三層系統資料：基礎層、平臺中介軟體層和應用層。其中，最重要的是把服務和相關的中介軟體以及主機關聯在一起，服務有可能執行在Docker 中，也有可能執行在微服務平臺上的多個 JVM 中，也有可能執行在 Tomcat 中。無論執行在哪裡,都要把服務的具體例項和主機關聯在一起，否則定位問題猶如大海撈針。

（3）快速故障定位。 做使用者請求跟蹤的 trace 監控，監控到所有的請求在分散式系統中的呼叫鏈，做成沒有侵入性的。

3.好的監控系統主要是為以下兩個場景所設計的

“體檢”

容量管理。 提供一個全域性的系統執行時資料的展示，可以讓工程師團隊知道是否需要增加機器或者其它資源。

效能管理。可以通過檢視大盤，找到系統瓶頸，並有針對性地優化系統和相應程式碼。

“急診”

定位問題。可以快速地暴露並找到問題的發生點，幫助技術人員診斷問題。

效能分析。當出現非預期的流量提升時，可以快速地找到系統的瓶頸，並可以幫助開發人員深入程式碼。

四、如何做出一個好的監控系統

1.服務呼叫鏈跟蹤

監控系統從對外的 API 開始，將後臺的實際服務關聯起來，服務的依賴服務給關聯起來，直到最後一個服務（如 MySQL 或 Redis），整個系統服務全部串連。

對於 Java 類的服務，使用位元組碼技術進行位元組碼注入，做無侵入式。

如下圖所示（截圖來自我做的一個 APM 的監控系統）。

2.服務呼叫時長分佈

下圖是 Zipkin 的服務呼叫時間分佈。可以看到一個服務呼叫鏈上的時間分佈，知道最耗時的服務是什麼。

3.服務的 TOP N 檢視

三種排名的方法：a）按呼叫量排名，b) 按請求最耗時排名，c）按熱點排名（一個時間段內的請求次數的響應時間和）。

4.資料庫操作關聯

對於 Java 應用，我們可以很方便地通過 JavaAgent 位元組碼注入技術拿到JDBC 執行資料庫操作的執行時間和相關的請求對應起來。

5.服務資源跟蹤。

我們的服務可能執行在物理機/虛擬機器裡/Docker 的容器裡(執行在物理機或是虛擬機器上)。我們需要把服務執行的機器節點上的資料（如 CPU、MEM、I/O、DISK、NETWORK）關聯起來。到如下的目標。

    當一臺機器掛掉是因為 CPU 或 I/O 過高、SQL 操作過慢、訊息佇列擁塞的時候，我們馬上可以知道其會影響到哪些對外服務API。

    當一個服務響應過慢的時候，我們馬上能關聯出來是否在做 Java GC，或是其所在的計算結點上是否有資源不足的情況，或是依賴的服務是否出現了問題。

一旦發現某個服務過慢是因為 CPU 使用過多，我們就可以做彈性伸縮。

一旦發現某個服務過慢是因為 MySQL 出現了一個慢查詢，做流量限制或降級操作了。

所以，一個分散式系統，或是一個自動化運維繫統，或是一個 Cloud Native 的雲化系統，最重要的事就是把監控系統做好。在把資料收集好、關聯好。這樣，我們才可能很快地定位故障，進而才能進行自動化排程。

上圖只是簡單地展示了一個分散式系統的服務呼叫連結上都在報錯，其根本原因是資料庫連結過多，服務不過來。另外一個原因是，Java 在做 Full GC 導致處理過慢。於是，訊息佇列出現訊息堆積堵塞。這個圖只是一個示例，其形象地體現了在分散式系統中監控資料關聯的重要性。