微服務架構學習與思考(14)：監控和可觀測性詳細介紹

一、APP故障小故事

在一個休息日的週六，你和朋友在公司附近逛街，突然，老闆來了一通電話：

老闆：小王，我們 APP 購物詳情頁面，怎麼突然訪問不了，一直在那裏加載，出了什麼 bug，趕緊看看？
小王：好的，老闆，你等等，我馬上回來看看是咋回事。

丟下朋友，一路小跑，火花帶閃電，奔回辦公室，開機找 bug。

修好 bug 後，就應該思考一下，老闆是咋發現這種情況？爲什麼他能先於我發現呢？有什麼好的手段處理這種情況，我能最先發現網站訪問異常？然後抓緊處理。

這時，你可能想到了對網站進行監控，化被動爲主動，主動去獲取 APP 異常信息。不錯，這是一個很好的方法。

二、爲什麼需要監控

從上面的小故事可以得到一些啓發，比如 APP 發生不能訪問的異常情況時，相關人員能夠快速感知到異常情況的發生，先於用戶得到異常情況的信息，能讓相關人員及時進行應急處理，減少損失。而不是等到多數用戶來報告異常情況纔去處理，這時損失就變大了。

監控系統不僅可以監控上面提到的應用程序頁面訪問異常，還可以監控其他頁面訪問流量，API 調用情況，響應時間，請求頻率，錯誤率等等，這些都關乎業務整體運行情況。

對應用程序本身也可以進行監控，比如 APM（應用程序性能監控）監控，這樣遇到應用程序故障時，可以快速定位問題、處理問題。

還有當運行應用程序服務器的 CPU、內存持續走高，磁盤存儲空間所剩不多等等各種異常情況，都需要監控來及時發現，並報給運維人員進行處理。

上面不管是業務訪問異常，還是服務器資源運行異常，還是 API 調用異常，程序出 bug 等各種異常情況，都需要及時發現並處理，目的是減少業務損失。

可以通過監控系統來及時發現異常情況，並通過系統記錄與異常相關聯的信息，還原異常出現的現場環境，從而協助運維或研發人員快速定位問題，並及時處理異常情況。

三、監控作用總結

爲什麼需要監控，除了上面說的作用外，下面對監控的作用做一些總結。（我理解的最大作用是：化被動爲主動）

近實時瞭解業務運行的健康狀況
提前獲知業務異常情況信息並告警通知
幫助定位各種異常、bug等故障
爲排障提供詳細信息
業務運營信息的統計和監控
監控系統資源使用情況，保障系統穩定運行
對異常情況發出告警通知，及時進行處理

四、監控系統流程

監控系統一般流程如下圖：

數據採集：

通過採集工具收集相關監控指標的數據，比如採集操作系統指標， CPU 使用率、內存使用率、TCP 連接數等等。常用的採集數據的方式有代理和埋點 2 種方式。
- 數據採集的軟件工具，有 Filebeat，Fluentd，Fluent Bit，LogStash，Promtai，Vector，Mtail，Flume 等等。
數據處理：

又可以叫數據計算處理，對採集到的原始數據進行各種緯度的計算處理，得到我們想要的一些監控指標數據。比如對於一些業務指標的計算，今天新增用戶的數、7 天新增用戶數、7 天某頁面的 UV 等等數據指標。
- 處理數據的工具有哪些？一般需要自己開發程序來進行數據處理，簡單的指標計算可以通過 SQL 來進行統計。數據量比較大統計實時性高，可以使用 storm，flink 等大數據計算框架來進行計算統計。
數據存儲：

這裏存儲有 3 層含義，第一個是對採集的原始數據進行存儲，第二個是對計算後的數據進行存儲。第三個是有時我們會對原始數據進行暫存處理，比如暫存在 kafka 中。
- 數據存儲軟件，數據暫存型的 kafka，關係型數據庫 MySQL、PostgrSQL，時序數據庫 InfluxDB、OpenTSDB、TimescaleDB，還有 Elasticsearch、MongoDB、ClickHouse、HBase、Hadoop 等等。
查詢分析、數據可視化：

查詢分析對監控的指標進行查看然後分析。數據可視化，用圖形方式展示監控的指標。
- 一般都是需要開發人員進行程序開發。log 型的日誌有 kibana 工具。
告警處理：

把系統發生的錯誤、異常信息及時通知給研發、運維等相關人員，讓他們及時進行處理。告警通知方式多種多樣，有短信、IM、郵件、Slack等等方式。
- 有簡單的告警設置，比如 prometheus 裏的。複雜的告警處理就需要研發來進行相關開發。

五、監控類別分層和指標

按照架構分層分類

根據業務系統架構設計，把監控系統類別進行分層，一般可分爲 4 層，如下簡圖：

上面是一個比較大的監控分類，大的監控類別還可以在細分爲一些小類和這些類別的一些監控指標，

業務監控：

這一層主要是對業務運營的指標和業務流程進行監控，隨時監控業務異常和 bug 狀況。

業務運營：日新增註冊用戶（7日，30日，當天等等），流失用戶數，活躍用戶數，每個頁面的 PV、UV，下單數量，支付數量、結算率等等數據
業務異常數據：比如某個頁面訪問異常統計，頁面 404,500 等統計
業務鏈路：業務鏈路中的關鍵節點，這些節點的健康情況、數據流向是否異常的監控
用戶體驗數據：頁面加載時間，交互響應時間等等，這些是前端監控數據的一部分

應用監控：

這一層主要是對應用程序運行情況進行監控，

API 監控：請求量、響應時間、耗時總長、超時比率，響應錯誤數、比率，比如 404,500 等統計
鏈路監控：API 請求之間的鏈路信息，比如鏈路的響應時間，耗時等
應用程序監控：對應用程序的持續監控，continue profiling。比如應用程序本身使用的內存，CPU 數，哪部分程序使用比較高

中間件監控：

一些使用的軟件，比如數據庫、Nginx、Redis、Kafka、K8S 等等軟件，這些軟件本身會給出一個接口，這個接口用來統計軟件自身的一些信息，可以收集這些信息，然後進行統計。還可以用產生的日誌進行統計。

比如說 Redis 的命令 redis info 就會顯示 Redis 的很多信息，可以摘出需要的信息進行記錄統計。

這裏每一個軟件都可以進行獨立的記錄和統計。比如數據庫，

數據庫：數據庫連接數，QPS，主從延遲，慢查詢，鎖的一些信息

基礎設施監控：

這裏的基礎設置包括一些硬件，比如交換機，物理磁盤，網卡狀態。還包括操作系統，網絡，虛擬機的監控

操作系統：CPU 使用率，內存使用情況，硬盤使用情況
網絡：TCP 連接數、連接狀態，網絡流入流出流量等網絡指標

按照監控內容分類

日誌類

日誌類就是指系統產生的日誌信息，代碼裏記錄的一些程序運行信息，還有一些業務級別上記錄的日誌信息，在帶上時間。

比如 Nginx 裏記錄的訪問日誌，應用記錄下用戶登錄日誌，用戶搜索記錄日誌，下單日誌數據，這些都是與用戶做某件事情相關聯的日誌信息。

有助於我們進行一些指標統計，異常信息查找和分析，告警通知。

調用鏈

調用鏈一般是指程序 API 之間相互調用的一些信息，端到端的訪問路徑相關信息，也叫鏈路追蹤。這些都是 APM 應用程序性能監控。

我前面有寫一篇關於 google 的 Dapper 鏈路追蹤文章，在這裏 https://www.cnblogs.com/jiujuan/p/16097314.html 。

度量類

度量類指的是記錄一串以時間爲緯度的數據，然後通過聚合統計，來計算一些監控指標。用來描述一些指標數據和指標變化趨勢，可以用圖表來表示。

在可觀測性裏這個叫 metrics 。

上面 3 個分類其實跟可觀測性的 3 個指標有點類似，下面就講一講可觀測性的內容。

六、可觀測性Observability

什麼是可觀測性

維基上：

控制理論中的可觀察性（observability）是指系統可以由其外部輸出推斷其其內部狀態的程度。系統的可觀察性和可控制性是數學上對偶的概念。它與可控制性（Controllability）一起，是由匈牙利數學家 Rudolf E. Kálmán 提出。

IBM：

一般來說，可觀察性是指您僅根據所瞭解的外部輸出對複雜系統內部狀態或條件的理解程度。系統的可觀察性越高，您就能越迅速、越準確地從發現的性能問題找到根本原因，而不必進行額外的測試或編碼。

From：https://www.ibm.com/cn-zh/topics/observability IBM的可觀測性

CNCF：

可觀察性是系統的一種屬性，描述了系統可以從其外部輸出中被理解的程度。

比如通過 CPU 使用時間、內存使用、磁盤空間、延遲、系統運行的錯誤信息等來衡量，計算機系統或多或少是可以被觀察到的狀況。聚合分析這些數據，您可以查看這些可觀察的數據來了解系統的運行狀況。

IBM 的定義和維基的差不多。

可觀測性是對軟件的一種度量能力。軟件是一個複雜系統，怎麼知道它的運行狀況是否健康呢？怎麼從外部窺見軟件的運行狀況和異常情況呢？怎麼分析出現的異常呢？通過軟件內部產生的數據信息（日誌信息、鏈路信息、profilling 等等各種信息）並輸出到外部，外部把這些信息通過聚合、計算，用一定的形式組織起來，然後用列表、圖表形式展現出來，這樣我們就可以肉眼去查看軟件系統各種緯度的情況、系統當前所處的狀態。

可觀測性就像一個顯微鏡，它仔細觀察軟件系統的各種指標和狀態，系統是否出現異常情況。

可觀測的三大支柱

可觀測性具體怎麼做？有哪些指標。

可觀測性一般有 3 個方向，分別是：事件日誌、鏈路追蹤和聚合度量，這 3 個方向各有自己的重點，又不是完全獨立的，它們有重合的地方。

可以看看 Peter Bourgon 的一篇總結文章《Metrics, Tracing, and Logging》，裏面有一張很經典圖片描述了 3 者之間的關係，受到了業界普遍的關注：

（圖片來源：《Metrics, Tracing, and Logging》）

指標（Metrics）、追蹤（Tracing）、日誌（Logging），這是可觀測性的3個基本指標。

日誌 logging

上面表示 Logging 是 events，它是特定時間發生離散事件的記錄。比如 Nginx 的訪問日誌記錄，每條日誌記錄一般有訪問時間戳、響應碼、頁面 URL、客戶端 IP 等信息。還有程序也會記錄一些用戶訪問信息，比如下單記錄。
鏈路追蹤 Tracing

端到端請求範圍內的調用鏈路相關信息。比如記錄每個請求階段的開始時間、時長等信息。關於 google 的 Dapper 鏈路追蹤文章，我前面寫的 https://www.cnblogs.com/jiujuan/p/16097314.html 。

鏈路追蹤主要是爲了排除故障，比如分析調用鏈中哪一部分用時比較長、哪個方法出錯了等等。
度量 Metrics
度量是對系統中某一類信息的聚合計算。比如服務器中 CPU 利用率、內存剩餘數，系統容量等等