我們可以這樣理解，監控系統就像我們的眼睛，幫助我們瞭解記錄系統到底發生什麼，幫助我們管理、運維整個系統。所以全棧監控其實非常非常關鍵。

而在分散式或 Cloud Native 的情況下，系統分成多層，服務各種關聯，需要監控的東西特別多。沒有一個好的監控系統，我們將無法進行自動化運維和資源排程。

這個監控系統需要 具備這些功能 ：

Ø  全棧監控；

Ø  關聯分析；

Ø  跨系統呼叫的串聯；

Ø  實時報警和自動處置；

Ø  系統效能分析。

多層體系的監控

所謂全棧監控，其實就是三層監控。

基礎層： 監控主機和底層資源。比如：CPU、記憶體、網路吞吐、硬碟 I/O、硬碟使用等。
中間層： 就是中介軟體層的監控。比如：Nginx、Redis、ActiveMQ、Kafka、MySQL、Tomcat 等。
應用層： 監控應用層的使用。比如：HTTP 訪問的吞吐量、響應時間、返回碼、呼叫鏈路分析、效能瓶頸，還包括使用者端的監控。

這還需要一些監控的標準化。

日誌資料結構化；
監控資料格式標準化；
統一的監控平臺；
統一的日誌分析。

什麼才是好的監控系統

市場上 很多監控系統都做得很不好，它們主要有兩個很大的問題。

1、監控資料 分割 。 因為公司分工的問題，開發、應用運維、系統運維，各管各的，所以很多公司的監控系統之間都有一道牆， 無法進入一個平臺分析。
2、監控的資料項太多。 有些運維 產品 把監控的資料項多 ， 做為一個亮點 ， 比如監控指標達到 5 萬多個 ，實際上這是不對的，資料資訊太多隻能證明沒有抓到監控重點，只是使用蠻力。

一個好的監控系統應該有以下幾個特徵

關注整體應用的 SLA。 主要從為使用者服務的 API 來監控整個系統。
關聯指標聚合。  把有關聯的系統及其指標聚合展示。主要是三層系統資料：基礎層、平臺中介軟體層和應用層。其中，最重要的是把服務和相關的中介軟體以及主機關聯在一起，服務有可能執行在 Docker 中，也有可能執行在微服務平臺上的多個 JVM 中，也有可能執行在 Tomcat 中。總之，無論執行在哪裡，我們都需要把服務的具體例項和主機關聯在一起，否則，對於一個分散式系統來說，定位問題猶如大海撈針。
快速故障定位。  對於現有的系統來說，故障總是會發生的，而且還會頻繁發生。故障發生不可怕，可怕的是故障的恢復時間過長。所以，快速地定位故障就相當關鍵。快速定位問題需要對整個分散式系統做一個使用者請求跟蹤的 trace 監控，我們需要監控到所有的請求在分散式系統中的呼叫鏈，這個事最好是做成沒有侵入性的。

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

服務呼叫鏈跟蹤。 這個監控系統應該從對外的 API 開始，然後將後臺的實際服務給關聯起來，然後再進一步將這個服務的依賴服務關聯起來，直到最後一個服務（如 MySQL 或 Redis），這樣就可以把整個系統的服務全部都串連起來了。這個事情的最佳實踐是 Google Dapper 系統，其對應於開源的實現是 Zipkin。對於 Java 類的服務，我們可以使用位元組碼技術進行位元組碼注入，做到程式碼無侵入式。

服務呼叫時長分佈。 使用 Zipkin，可以看到一個服務呼叫鏈上的時間分佈，這樣有助於我們知道最耗時的服務是什麼。

服務的 TOP N 檢視。 所謂 TOP N 檢視就是一個系統請求的排名情況。一般來說，這個排名會有三種排名的方法：a）按呼叫量排名，b) 按請求最耗時排名，c）按熱點排名（一個時間段內的請求次數的響應時間和）。

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

服務資源跟蹤。 我們的服務可能執行在物理機上，也可能執行在虛擬機器裡，還可能執行在一個 Docker 的容器裡，Docker 容器又執行在物理機或是虛擬機器上。我們需要把服務執行的機器節點上的資料（如 CPU、MEM、I/O、DISK、NETWORK）關聯起來。

這樣一來，我們就可以知道服務和基礎層資源的關係。如果是 Java 應用，我們還要和 JVM 裡的東西進行關聯，這樣我們才能知道服務所執行的 JVM 中的情況（比如 GC 的情況）。

有了這些資料上的關聯，我們就可以達到如下的目標。

1、當一臺機器掛掉是因為 CPU 或 I/O 過高的時候，我們馬上可以知道其會影響到哪些對外服務的 API。
2、當一個服務響應過慢的時候，我們馬上能關聯出來是否在做 Java GC，或是其所在的計算結點上是否有資源不足的情況，或是依賴的服務是否出現了問題。
3、當發現一個 SQL 操作過慢的時候，我們能馬上知道其會影響哪個對外服務的 API。
4、當發現一個訊息佇列擁塞的時候，我們能馬上知道其會影響哪些對外服務的 API。

總之，我們就是想知道使用者訪問哪些請求會出現問題，這對於我們瞭解故障的影響面非常有幫助。

一旦瞭解了這些資訊，我們就可以做出排程。比如：

一旦發現某個服務過慢是因為 CPU 使用過多，我們就可以做彈性伸縮。
一旦發現某個服務過慢是因為 MySQL 出現了一個慢查詢，我們就無法在應用層上做彈性伸縮，只能做流量限制，或是降級操作了。

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

 

 

 

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