想吃透監控系統，就這一篇夠不夠?

2021-02-13 分類：網站建設

經濟高速發展的今天，我們處于信息大爆炸的時代。隨著經濟發展，信息借助互聯網的力量在全球自由地流動，于是就催生了各種各樣的服務平臺和軟件系統。

圖片來自 Pexels

由于業務的多樣性，這些平臺和系統也變得異常的復雜。如何對其進行監控和維護是我們 IT 人需要面對的重要問題。就在這樣一個紛繁復雜地環境下，監控系統粉墨登場了。

今天，我們會對 IT 監控系統進行介紹，包括其功能，分類，分層;同時也會介紹幾款流行的監控平臺。

監控系統的功能

在 IT 運維過程中，常遇到這樣的情況：

某個業務模塊出現問題，運維人員并不知道，發現的時候問題已經很嚴重了。
系統出現瓶頸了，CPU 占用持續升高，內存不足，磁盤被寫滿;網絡請求突增，超出網關承受的壓力。

以上這些問題一旦發生，會對我們的業務產生巨大的影響。因此，每個公司或者 IT 團隊都會針對此類情況建立自己的 IT 監控系統。

Java 代碼運行原理圖

在介紹這種方式之前，我們先來復習一下 Java 代碼運行的原理。通常我們會把 Java 源代碼，通過“Java 編譯器”編譯成 Class 文件。再把這個 Class 的字節碼文件裝載到“類裝載器”中進行字節碼的驗證。

最后，把驗證過后的字節碼發送到“Java 解釋器”和“及時編譯器”交給“Java 運行系統”運行。

Java 探針，字節碼增強的方式就是利用 Java 代理，這個代理是運行方法之前的攔截器。

在 JVM 加載 Class 二進制文件的時候，利用 ASM 動態的修改加載的 Class 文件，在監控的方法前后添加需要監控的內容。

例如：添加計時語句，用于記錄方法耗時。將方法耗時存入處理器，利用棧先特性(先進后出)處理方法調用順序。

每當請求處理結束后，將耗時方法和入參 map 輸出到文件中，然后根據 map 中相應參數，區分出耗時業務。

最后將相應耗時文件取下來，轉化為 xml 格式并進行解析，通過瀏覽器將代碼分層結構展示出來。

時序數據庫數據模型圖例

時序數據庫的存儲原理，關系型數據庫存儲采用的是 B tree，雖然降低了數據查詢的磁盤尋道時間，但是無法解決大量數據寫入時的磁盤效率。

由于監控系統的應用場景，經常會遇到大批量的數據寫入，所以我們會選擇 LSMtree(Log Structured Merge Tree)存儲時序數據庫。

LSMtree(Log Structured Merge Tree)，從字面意義上理解，記錄的數據按照日志結構(Log Structured)追加到系統中，然后通過合并樹(Merge Tree)的方式將其合并。

來看一個 LevelDB 的例子，方便我們理解，LSM-tree 被分成三種文件：

接收寫入請求的 memtable 文件(內存中)
不可修改的 immutable memtable 文件(內存中)
磁盤上的 SStable文件(Sorted String Table)，有序字符串表，這個有序的字符串就是數據的key。SStable 一共有七層(L0 到 L6)。下一層的總大小限制是上一層的 10 倍。

LSMtree LevelDB 存儲示意圖

LSMtree 寫入流程：

將數據追加到日志 WAL(Write Ahead Log)中，寫入日志的目的是為了防止內存數據丟失，可以及時恢復。
把數據寫到 memtable 中。
當 memtable 滿了(超過一定閥值)，就將這個 memtable 轉入 immutable memtable 中，用新的 memtable 接收新的數據請求。
immutablememtable 一旦寫滿了，就寫入磁盤。并且先存儲 L0 層的 SSTable 磁盤文件，此時還不需要做文件的合并。

每層的所有文件總大小是有限制的(8MB，10MB，100MB… 1TB)。從 L1 層往后，每下一層容量增大十倍。

某一層的數據文件總量超過閾值，就在這一層中選擇一個文件和下一層的文件進行合并。

如此這般上層的數據都是較新的數據，查詢可以從上層開始查找，依次往下，并且這些數據都是按照時間序列存放的。

監控系統的分層

談完了監控系統的分類，再來聊聊監控系統的分層。用戶請求到數據返回，經歷系統中的層層關卡。

監控系統分層示意圖

一般我們將監控系統分為五層來考慮，當然也有人分成三層，大致的意思都差不多，僅供參考：

客戶端監控，用戶行為信息，業務返回碼，客戶端性能，運營商，版本，操作系統等。

業務層監控，核心業務的監控，例如：登錄，注冊，下單，支付等等。

應用層監控，相關的技術參數，例如：URL 請求次數，Service 請求數量，SQL 執行的結果，Cache 的利用率，QPS 等等。

系統層監控，物理

Zabbix 的部署模式

Zabbix 的數據采集，主要有兩種模式：Server 主動拉取數據和 Agent 主動上報數據。

以 Server 拉取數據為例，用戶在 Web-portal 中，設置需要監控的機器，配置監控項，告警策略。Zabbix-Server 會根據策略主動獲取 Agent 的數據，然后存儲到 MySQL 中。

同時根據用戶配置的策略，判定是否需要告警。用戶可以在 Web 端，以圖表的形式，查看各種指標的歷史趨勢。

在 Zabbix 中，將 Server 主動拉取數據的方式稱之為 Active Check。這種方式配置起來較為方便，但是會對 Zabbix-Server 的性能存在影響。

所以在生產環境中，一般會選擇主動推送數據到 Zabbix-Server 的方式，稱之為 Trapper。

即用戶可以定時生成數據，再按照 Zabbix 定義的數據格式，批量發送給 Zabbix-Server，這樣可以大大提高 Server 的處理能力。

Proxy，作為可選項，起到收集 Agent 數據并且轉發到 Server 的作用。

當 Server 和 Agent 不在一個網絡內，就需要使用 Proxy 做遠程監控，特別是遠程網絡有防火墻的時候。同時它也可以分擔 Server 的壓力，降低 Server 處理連接數的開銷。

Prometheus(普羅米修斯)

隨著這幾年云環境的發展，Prometheus 被廣泛地認可。它的本質是時間序列數據庫，而 Zabbix 采用 MySQL 進行數據存儲。

從上面我們對時間序列數據庫的分析來看，Prometheus 能夠很好地支持大量數據的寫入。

它采用拉的模式(Pull)從應用中拉取數據，并通過 Alert 模塊實現監控預警。據說單機可以消費百萬級時間序列。

一起來看看 Prometheus 的幾大組件：

Prometheus Server，用于收集和存儲時間序列數據，負責監控數據的獲取，存儲以及查詢。
監控目標配置，Prometheus Server 可以通過靜態配置管理監控目標，也可以配合 Service Discovery(K8s，DNS，Consul)實現動態管理監控目標。
監控目標存儲，Prometheus Server 本身就是一個時序數據庫，將采集到的監控數據按照時間序列存儲在本地磁盤中。
監控數據查詢，Prometheus Server 對外提供了自定義的 PromQL 語言，實現對數據的查詢以及分析。
Client Library，客戶端庫。為需要監控的服務生成相應的 Metrics 并暴露給 Prometheus Server。
當 Prometheus Server 來 Pull 時，直接返回實時狀態的 Metrics。通常會和 Job 一起合作。
Push Gateway，主要用于短期的 Jobs。由于這類 Jobs 存在時間較短，可能在 Prometheus 來 Pull 之前就消失了。為此，這些 Jobs 可以直接向 Prometheus Server 端推送它們的 Metrics。
Exporters，第三方服務接口。將 Metrics(數據集合)發送給 Prometheus。
Exporter 將監控數據采集的端點，通過 HTTP 的形式暴露給 Prometheus Server，使其通過 Endpoint 端點獲取監控數據。
Alertmanager，從 Prometheus Server 端接收到 Alerts 后，會對數據進行處理。例如：去重，分組，然后根據規則，發出報警。
Web UI，Prometheus Server 內置的 Express Browser UI，通過 PromQL 實現數據的查詢以及可視化。

Prometheus 架構圖

說完了 Prometheus 的組件，再來看看 Prometheus 的架構：

Prometheus Server 定期從 Jobs/Exporters 中拉 Metrics。同時也可以接收來自 Pushgateway 發過來的 Metrics。
Prometheus Server 將接受到的數據存儲在本地時序數據庫，并運行已定義好的 alert.rules(告警規則)，一旦滿足告警規則就會向 Alertmanager 推送警報。
Alertmanager 根據配置文件，對接收到的警報進行處理，例如：發出郵件告警，或者借助第三方組件進行告警。
WebUI/Grafana/APIclients，可以借助 PromQL 對監控數據進行查詢。

最后將兩個工具進行比較如下：

Zabbix 和 Prometheus 比較圖

從上面的比較可以看出：

Zabbix 的成熟度更高，上手更快。高集成度導致靈活性較差，在監控復雜度增加后，定制難度會升高。而且使用的關系型數據庫，對于大規模的監控數據插入和查詢是個問題。
Prometheus 上手難度大，定制靈活度高，有較多數據聚合的可能，而且有時序數據庫的加持。
對于監控物理機或者監控環境相對穩定的情況，Zabbix 有明顯優勢。如果監控場景多是云環境的話，推薦使用 Prometheus。

總結