經(jīng)濟(jì)高速發(fā)展的今天，我們處于信息大爆炸的時代。隨著經(jīng)濟(jì)發(fā)展，信息借助互聯(lián)網(wǎng)的力量在全球自由地流動，于是就催生了各種各樣的服務(wù)平臺和軟件系統(tǒng)。

圖片來自 Pexels

由于業(yè)務(wù)的多樣性，這些平臺和系統(tǒng)也變得異常的復(fù)雜。如何對其進(jìn)行監(jiān)控和維護(hù)是我們 IT 人需要面對的重要問題。就在這樣一個紛繁復(fù)雜地環(huán)境下，監(jiān)控系統(tǒng)粉墨登場了。

今天，我們會對 IT 監(jiān)控系統(tǒng)進(jìn)行介紹，包括其功能，分類，分層;同時也會介紹幾款流行的監(jiān)控平臺。

監(jiān)控系統(tǒng)的功能

在 IT 運(yùn)維過程中，常遇到這樣的情況：

• 某個業(yè)務(wù)模塊出現(xiàn)問題，運(yùn)維人員并不知道，發(fā)現(xiàn)的時候問題已經(jīng)很嚴(yán)重了。
• 系統(tǒng)出現(xiàn)瓶頸了，CPU 占用持續(xù)升高，內(nèi)存不足，磁盤被寫滿;網(wǎng)絡(luò)請求突增，超出網(wǎng)關(guān)承受的壓力。

以上這些問題一旦發(fā)生，會對我們的業(yè)務(wù)產(chǎn)生巨大的影響。因此，每個公司或者 IT 團(tuán)隊(duì)都會針對此類情況建立自己的 IT 監(jiān)控系統(tǒng)。

Java 代碼運(yùn)行原理圖

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

最后，把驗(yàn)證過后的字節(jié)碼發(fā)送到“Java 解釋器”和“及時編譯器”交給“Java 運(yùn)行系統(tǒng)”運(yùn)行。

Java 探針，字節(jié)碼增強(qiáng)的方式就是利用 Java 代理，這個代理是運(yùn)行方法之前的攔截器。

在 JVM 加載 Class 二進(jìn)制文件的時候，利用 ASM 動態(tài)的修改加載的 Class 文件，在監(jiān)控的方法前后添加需要監(jiān)控的內(nèi)容。

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

每當(dāng)請求處理結(jié)束后，將耗時方法和入?yún)?map 輸出到文件中，然后根據(jù) map 中相應(yīng)參數(shù)，區(qū)分出耗時業(yè)務(wù)。

最后將相應(yīng)耗時文件取下來，轉(zhuǎn)化為 xml 格式并進(jìn)行解析，通過瀏覽器將代碼分層結(jié)構(gòu)展示出來。

時序數(shù)據(jù)庫數(shù)據(jù)模型圖例

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

由于監(jiān)控系統(tǒng)的應(yīng)用場景，經(jīng)常會遇到大批量的數(shù)據(jù)寫入，所以我們會選擇 LSMtree(Log Structured Merge Tree)存儲時序數(shù)據(jù)庫。

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

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

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

LSMtree LevelDB 存儲示意圖

LSMtree 寫入流程：

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

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

• 某一層的數(shù)據(jù)文件總量超過閾值，就在這一層中選擇一個文件和下一層的文件進(jìn)行合并。

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

監(jiān)控系統(tǒng)的分層

談完了監(jiān)控系統(tǒng)的分類，再來聊聊監(jiān)控系統(tǒng)的分層。用戶請求到數(shù)據(jù)返回，經(jīng)歷系統(tǒng)中的層層關(guān)卡。

監(jiān)控系統(tǒng)分層示意圖

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

客戶端監(jiān)控，用戶行為信息，業(yè)務(wù)返回碼，客戶端性能，運(yùn)營商，版本，操作系統(tǒng)等。

業(yè)務(wù)層監(jiān)控，核心業(yè)務(wù)的監(jiān)控，例如：登錄，注冊，下單，支付等等。

應(yīng)用層監(jiān)控，相關(guān)的技術(shù)參數(shù)，例如：URL 請求次數(shù)，Service 請求數(shù)量，SQL 執(zhí)行的結(jié)果，Cache 的利用率，QPS 等等。

系統(tǒng)層監(jiān)控，物理

Zabbix 的部署模式

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

以 Server 拉取數(shù)據(jù)為例，用戶在 Web-portal 中，設(shè)置需要監(jiān)控的機(jī)器，配置監(jiān)控項(xiàng)，告警策略。Zabbix-Server 會根據(jù)策略主動獲取 Agent 的數(shù)據(jù)，然后存儲到 MySQL 中。

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

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

所以在生產(chǎn)環(huán)境中，一般會選擇主動推送數(shù)據(jù)到 Zabbix-Server 的方式，稱之為 Trapper。

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

Proxy，作為可選項(xiàng)，起到收集 Agent 數(shù)據(jù)并且轉(zhuǎn)發(fā)到 Server 的作用。

當(dāng) Server 和 Agent 不在一個網(wǎng)絡(luò)內(nèi)，就需要使用 Proxy 做遠(yuǎn)程監(jiān)控，特別是遠(yuǎn)程網(wǎng)絡(luò)有防火墻的時候。同時它也可以分擔(dān) Server 的壓力，降低 Server 處理連接數(shù)的開銷。

Prometheus(普羅米修斯)

隨著這幾年云環(huán)境的發(fā)展，Prometheus 被廣泛地認(rèn)可。它的本質(zhì)是時間序列數(shù)據(jù)庫，而 Zabbix 采用 MySQL 進(jìn)行數(shù)據(jù)存儲。

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

它采用拉的模式(Pull)從應(yīng)用中拉取數(shù)據(jù)，并通過 Alert 模塊實(shí)現(xiàn)監(jiān)控預(yù)警。據(jù)說單機(jī)可以消費(fèi)百萬級時間序列。

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

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

Prometheus 架構(gòu)圖

說完了 Prometheus 的組件，再來看看 Prometheus 的架構(gòu)：

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

最后將兩個工具進(jìn)行比較如下：

Zabbix 和 Prometheus 比較圖

從上面的比較可以看出：

• Zabbix 的成熟度更高，上手更快。高集成度導(dǎo)致靈活性較差，在監(jiān)控復(fù)雜度增加后，定制難度會升高。而且使用的關(guān)系型數(shù)據(jù)庫，對于大規(guī)模的監(jiān)控?cái)?shù)據(jù)插入和查詢是個問題。
• Prometheus 上手難度大，定制靈活度高，有較多數(shù)據(jù)聚合的可能，而且有時序數(shù)據(jù)庫的加持。
• 對于監(jiān)控物理機(jī)或者監(jiān)控環(huán)境相對穩(wěn)定的情況，Zabbix 有明顯優(yōu)勢。如果監(jiān)控場景多是云環(huán)境的話，推薦使用 Prometheus。

總結(jié)

監(jiān)控系統(tǒng)思維導(dǎo)圖

監(jiān)控系統(tǒng)對 IT 系統(tǒng)運(yùn)維意義重大，從狀態(tài)監(jiān)控到收集/分析數(shù)據(jù)，到故障報警，以及問題解決，最后歸檔報表，協(xié)助運(yùn)維復(fù)盤。

監(jiān)控系統(tǒng)分為三大類，日志類，調(diào)用鏈類，度量類，他們有各自的特點(diǎn)，且應(yīng)用場景各不相同。

因?yàn)橐獙φ麄€ IT 系統(tǒng)進(jìn)行監(jiān)控，所以將其分為五層，分別是，客戶端，業(yè)務(wù)層，應(yīng)用層，系統(tǒng)層，網(wǎng)絡(luò)層。

Zabbix 和 Prometheus 是當(dāng)下流行的監(jiān)控系統(tǒng)，可以根據(jù)他們的特點(diǎn)選擇使用。

文章題目：想吃透監(jiān)控系統(tǒng)，就這一篇夠不夠?
地址分享：http://www.rwnh.cn/news/100696.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供建站公司、網(wǎng)站內(nèi)鏈、網(wǎng)站改版、品牌網(wǎng)站制作、營銷型網(wǎng)站建設(shè)、網(wǎng)站排名

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)