為什麼要有監控系統

在我從業4年多的歷程中，大部分時間是沒有接觸監控系統的或者沒有發現監控系統的重要性。這很正常，因為IT界的演化本質上是從簡單到複雜從單節點到叢集，從裸金屬到完全託管雲服務的過程。

我工作過程中接觸到的技術演變大致也是就如上，也大致經歷了這幾個階段。

第一階段:

Java SSM單體應用+dubbo rpc

手動在單體應用所在的伺服器上逐個手動shell檢索資料

沒有對單體應用的節點健康，效能，壓力監控

沒有鏈路追蹤

這是最基礎的服務，勉強有了微服務的概念本質上還是單體，沒有任何的觀察系統概念。但是這個在當年還是夠用的，因為單體應用這時數量有限，即使分散到各個伺服器但是手動查詢還是勉強應付。

第二階段:

Java Spring Cloud微服務，部署到裸金屬上

手動在單體應用所在的伺服器上逐個手動shell檢索日誌資料

自帶簡單的單體應用的節點健康檢查和容錯

自帶簡單的鏈路追蹤

這時有了基本的服務拆分和微服務的雛形了，但是還沒有做到服務節點的動態伸縮。 這時節點的數量比較多了，手動檢索日誌資訊開始有點費力，產生了一些觀察系統的需求和必要性。

第三階段:

Java Spring Cloud微服務，使用K8S編排

日誌資料按照節點的型別做了集中的儲存，儲存在ES中，在Kibana檢索集中起來的資料，不必到每個容器中檢索了

自帶初級的單體應用的節點健康檢查和容錯

自帶初級的鏈路追蹤

除了日誌的檢索升級了，其餘的功能比如狀態自動感知完全沒有

這時有了動態伸縮了，手動檢索節點的日誌資料變得不可能，但是觀察系統沒有成形。只好透過ELK技術集中儲存日誌然後搜尋，觀察系統變成了非常重要的平臺需求

第四階段:

完全上雲，使用Serverless+K8S容器話。並且語言不再是java一種而是變成了Java/Python/Node/Go

基本沒有了節點的概念，無法知道確切的服務節點拓撲和數量，ELK的簡單使用只能解決分散式日誌源頭聚合和檢索的問題

在這個時候，觀察系統已經變成了剛需，沒有好的觀察系統團隊很難直觀的知道當下的服務壓力和資源耗費詳細情況，這樣就會嚴重現在團隊的開發能力和故障反應能力。

總結

在容器化，雲原生，serverles等新技術的大量使用現實下，以往的手動/半手動日誌檢索已經完全不能繼續產生任何價值。 它給整個開發團隊提出瞭如下挑戰

不單是是日誌的檢索。新的技術的使用也對現在的後端服務提出了一些新的要求，比如效能監控，故障自動感知，鏈路追蹤，高壓力下的自動彈性處理等等。 在這個場景下，一個好的觀察系統必須做到這些基本的功能，不單是日誌收集和檢索

它呈現給我們那些方面的資訊

首先是系統多維的狀態資訊：

各種型別的日誌資料。做到分散式收集->集中儲存->資料索引->靈活檢索

服務的指標資料

服務壓力感知和指標資料

服務健康度監控

各服務間相互協作和呼叫時的效能情況

APM資料

隨時間線發展而產生的外界壓力曲線以及這些時間點上對應的平臺的效能表現

使用者的使用喜好和週期性規律

服務uptime

Serverless服務的消費時長，單個請求的服務耗時

容器的全生命週期中服務時長

裸金屬伺服器的啟停時間

其中ELK技術棧大致能解決大部分的問題

不過鏈路追蹤和更豐富的視覺化展現。ELK做的不是100%的完美，它需要在跨語言跨技術體系的日誌設計這個頂層的設計上結合最合適的元件完成鏈路追蹤。同時資料的視覺化上Kibana有時略顯單一。 業界一般使用ELK+Grafana+Prometheus+雲服務商的監控（比如AWS CloudWatch）完成更加立體的

日誌/指標收集->資料儲存->資料的分析（解析，提取，索引。。）->資料的高階感知（服務鏈路流程感知，自動告警，自動擴縮容，自動壓力分配，自動的資源預先準備）->資料的展現（圖形化展示，資料檢索，趨勢分析）

它怎麼展現

在資料視覺化上，一般我們喜歡叫它‘大屏’，關於展示的技術一般這個沒有標準，業界比較流行的是Kibana或者Grafana，以Grafana相對更加專業一些。

它需要那些資料

主要是如下的基礎資料：

日誌資料，文字型別或者流式傳輸都可，不限於日誌的傳輸形式，但是日誌是要有格式或者能被預格式化的，這樣方便自動化/人工的解讀。單條日誌是單個事件，代表某個時間點某個服務做了什麼，是點資訊

服務資源指標，這方面的資料有少量是有具體格式並做了記錄的的，比如MySQL慢查詢日誌，但是大部分是實時的非記錄的，比如伺服器的CPU資源佔用預設就沒有日誌記錄，這也是點資訊。

伺服器，服務節點等的心跳資訊，用於確定時間點的健康，這也是點資訊。

服務鏈路中的traceId，如果沒有traceId或者類似的追蹤定位點，那麼一個網路請求過來經過了那些點是沒法做時間前後順序的鏈路連線的，也就是點無法連成線。這是針對某個流程，觀測其演變過程，前因後果我們成為線資訊。

上述的基礎資訊從產生資料的源進行獲取，比如MySQL，Serverless例項，容器化節點，雲廠商專有服務（SNS，SQS。。。）

在某個時間視窗，觀測某些指標的規律，以及指標與指標之間的聯絡我們叫做面資訊。基於上述的基礎資料，分析服務間的協同狀況，將上面的線連成面才有可能才能形成服務間關聯關係的感知。

對於整個平臺全部服務的點->線->面的全域性多維度感知和自動處理是一個好的觀察系統的本質訴求，同時記錄面隨時間線的資料，聚合為更加完善的立體觀察平臺是這個系統的理想狀態。

實現觀察系統的技術層次模型

想了解更多精彩內容，快來關注計算機java程式設計