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

?

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

圖片來(lái)自 Pexels

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

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

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

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

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

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

監(jiān)控系統(tǒng)工作流程圖

其功能包括：

• 對(duì)服務(wù)，系統(tǒng)，平臺(tái)的運(yùn)行狀態(tài)實(shí)時(shí)監(jiān)控。
• 收集服務(wù)，系統(tǒng)，平臺(tái)的運(yùn)行信息。
• 通過(guò)收集信息的分析結(jié)果，預(yù)知存在的故障風(fēng)險(xiǎn)，并采取行動(dòng)。
• 根據(jù)對(duì)風(fēng)險(xiǎn)的評(píng)估，進(jìn)行故障預(yù)警。
• 一旦發(fā)生故障，第一時(shí)間發(fā)出告警信息。
• 通過(guò)監(jiān)控?cái)?shù)據(jù)，定位故障，協(xié)助生成解決方案。
• 最終保證系統(tǒng)持續(xù)、穩(wěn)定、安全運(yùn)行。
• 監(jiān)控?cái)?shù)據(jù)可視化，便于統(tǒng)計(jì)，按照一定周期導(dǎo)出、歸檔，用于數(shù)據(jù)分析和問(wèn)題復(fù)盤。

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

既然監(jiān)控系統(tǒng)對(duì)我們意義重大，針對(duì)不同場(chǎng)景把監(jiān)控系統(tǒng)分為三類，分別是：

• 日志類
• 調(diào)用鏈類
• 度量類

日志類

通常我們?cè)谙到y(tǒng)和業(yè)務(wù)級(jí)別上加入一些日志代碼，記錄一些日志信息，方便我們?cè)诎l(fā)現(xiàn)問(wèn)題的時(shí)候查找。

這些信息會(huì)與事件做相關(guān)，例如：用戶登錄，下訂單，用戶瀏覽某件商品，一小時(shí)以內(nèi)的網(wǎng)關(guān)流量，用戶平均響應(yīng)時(shí)間等等。

這類以日志的記錄和查詢的解決方案比較多。比如 ELK 方案(Elasticsearch+Logstash+Kibana)，使用ELK(Elasticsearch、Logstash、Kibana)+Kafka/Redis/RabbitMQ 來(lái)搭建一個(gè)日志系統(tǒng)。

ELK 結(jié)合 Redis/Kafka/RabbitMQ 實(shí)現(xiàn)日志類監(jiān)控

程序內(nèi)部通過(guò) Spring AOP 記錄日志，Beats 收集日志文件，然后用 Kafka/Redis/RabbitMQ 將其發(fā)送給 Logstash，Logstash 再將日志寫入 Elasticsearch。

最后，使用 Kibana 將存放在 Elasticsearch 中的日志數(shù)據(jù)顯示出來(lái)，形式可以是實(shí)時(shí)數(shù)據(jù)圖表。

調(diào)用鏈類

對(duì)于服務(wù)較多的系統(tǒng)，特別是微服務(wù)系統(tǒng)。一次服務(wù)的調(diào)用有可能涉及到多個(gè)服務(wù)。A 調(diào)用 B，B 又要調(diào)用 C，好像一個(gè)鏈條一樣，形成了服務(wù)調(diào)用鏈。

調(diào)用鏈就是記錄一個(gè)請(qǐng)求經(jīng)過(guò)所有服務(wù)的過(guò)程。請(qǐng)求從開(kāi)始進(jìn)入服務(wù)，經(jīng)過(guò)不同的服務(wù)節(jié)點(diǎn)后，再返回給客戶端，通過(guò)調(diào)用鏈參數(shù)來(lái)追蹤全鏈路行為。從而知道請(qǐng)求在哪個(gè)環(huán)節(jié)出了故障，系統(tǒng)的瓶頸在哪兒。

調(diào)用鏈監(jiān)控的實(shí)現(xiàn)原理如下：

①Java 探針，字節(jié)碼增強(qiáng)

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

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

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

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

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

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

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

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

Java 探針工具原理圖

備注：ASM 是一個(gè) Java 字節(jié)碼操縱框架，它可以動(dòng)態(tài)生成類或者增強(qiáng)既有類的功能。

ASM 可以直接產(chǎn)生二進(jìn)制 Class 文件，可以在類被載入 Java 虛擬機(jī)之前改變類行為。

Java Class 被存儲(chǔ)在 .class文件里，文件擁有元數(shù)據(jù)來(lái)解析類中的元素：類名稱、方法、屬性以及 Java 字節(jié)碼(指令)。

ASM 從類文件中讀入信息后，能夠改變類行為，分析類信息，甚至能夠生成新類。

②攔截請(qǐng)求

獲取每次請(qǐng)求服務(wù)中的信息來(lái)實(shí)現(xiàn)跟蹤的。這里以 Zipkin+Slueth 為例說(shuō)明其原理。

Sleuth 提供鏈路追蹤。由于一個(gè)請(qǐng)求會(huì)涉及到多個(gè)服務(wù)的互相調(diào)用，而這種調(diào)用往往成鏈?zhǔn)浇Y(jié)構(gòu)，經(jīng)過(guò)多次層層調(diào)用以后請(qǐng)求才會(huì)返回。常常使用 Sleuth 追蹤整個(gè)調(diào)用過(guò)程，方便理清服務(wù)間的調(diào)用關(guān)系。

Sleuth 服務(wù)調(diào)用追蹤圖例

每次請(qǐng)求都會(huì)生成一個(gè) Trace ID，如上圖所示這個(gè) Trace ID 在整個(gè) Request 和 Response 過(guò)程中都會(huì)保持一致，不論經(jīng)過(guò)了多少個(gè)服務(wù)。這是為了方便記錄一次調(diào)用的整個(gè)生命周期。

再看每次請(qǐng)求的時(shí)候都會(huì)有一個(gè) Span ID，這里的 Span 是 Sleuth 服務(wù)跟蹤的最小單元，每經(jīng)過(guò)一個(gè)服務(wù)，每次 Request 和 Response 這個(gè)值都會(huì)有所不同，這是為了區(qū)分不同的調(diào)用動(dòng)作。

針對(duì)每個(gè)調(diào)用的動(dòng)作，Sleuth 都做了標(biāo)示如下：

• Server Received 是服務(wù)器接受，也就是服務(wù)端接受到請(qǐng)求的意思。
• Client Sent 是客戶端發(fā)送，也就是這個(gè)服務(wù)本身不提供響應(yīng)，需要調(diào)用其他的服務(wù)提供該響應(yīng)，所以這個(gè)時(shí)候是作為客戶端發(fā)起請(qǐng)求的。
• Server Sent 是服務(wù)端發(fā)送，看上圖SERVICE 3 收到請(qǐng)求后，由于他是最終的服務(wù)提供者，所以作為服務(wù)端，他需要把請(qǐng)求發(fā)送給調(diào)用者。
• Client Received 是客戶端接受，作為發(fā)起調(diào)用的客戶端接受到服務(wù)端返回的請(qǐng)求。

實(shí)際上 Sleuth 就是通過(guò)上述方式把每次請(qǐng)求記錄一個(gè)統(tǒng)一的 Trace ID，每個(gè)請(qǐng)求的詳細(xì)步驟記作 Span ID。

每次發(fā)起請(qǐng)求或者接受請(qǐng)求的狀態(tài)分別記錄成 Server Received，Client Sent，Server Sent，Client Received 四種狀態(tài)來(lái)完成這個(gè)服務(wù)調(diào)用鏈路的跟蹤的。

Sleuth 服務(wù)調(diào)用追蹤圖例

在調(diào)用服務(wù)的鏈路上每個(gè)被調(diào)用的服務(wù)節(jié)點(diǎn)都會(huì)通過(guò) Parent ID 來(lái)記錄發(fā)起調(diào)用服務(wù)的 Span ID，由于 Span ID 是唯一確認(rèn)最小服務(wù)單元的，所以知道了 Parent 的 Span ID 也就知道了誰(shuí)調(diào)用自己了。

度量類

實(shí)現(xiàn)了時(shí)序數(shù)據(jù)庫(kù)(TimeSeriesData，TSD)的監(jiān)控方案。實(shí)際上就是記錄一串以時(shí)間為維度的數(shù)據(jù)，然后再通過(guò)聚合運(yùn)算，查看指標(biāo)數(shù)據(jù)和指標(biāo)趨勢(shì)。說(shuō)白了，就是描述某個(gè)被測(cè)主體在一段時(shí)間內(nèi)的測(cè)量值變化(度量)。

由于 IT 基礎(chǔ)設(shè)施，運(yùn)維監(jiān)控和互聯(lián)網(wǎng)監(jiān)控的特性，這種方式被廣泛應(yīng)用。一般對(duì)時(shí)序數(shù)據(jù)進(jìn)行建模分為三個(gè)部分，分別是：主體，時(shí)間點(diǎn)和測(cè)量值。

通過(guò)這個(gè)例子來(lái)看一下，時(shí)序數(shù)據(jù)庫(kù)的數(shù)學(xué)模型，例如：需要監(jiān)控服務(wù)器的 In/Out 平均流量：

• 整個(gè)監(jiān)控的數(shù)據(jù)庫(kù)稱為“Metric”，它包含了所有監(jiān)控的數(shù)據(jù)。類似關(guān)系型數(shù)據(jù)庫(kù)中的 Table。
• 每條監(jiān)控?cái)?shù)據(jù)，稱為“Point”，類似于關(guān)系型數(shù)據(jù)庫(kù)中的 Row 的概念。
• 每個(gè)“Point”都會(huì)定義一個(gè)時(shí)間戳“Timestamp”，將其作為索引，表明數(shù)據(jù)采集的時(shí)間。
• “Tag”作為維度列，表示監(jiān)控?cái)?shù)據(jù)的屬性。
• “Field”作為指標(biāo)列，作為測(cè)量值，也就是測(cè)量的結(jié)果。

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

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

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

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

來(lái)看一個(gè) LevelDB 的例子，方便我們理解，LSM-tree 被分成三種文件：

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

LSMtree LevelDB 存儲(chǔ)示意圖

LSMtree 寫入流程：

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

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

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

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

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

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

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

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

• 客戶端監(jiān)控，用戶行為信息，業(yè)務(wù)返回碼，客戶端性能，運(yùn)營(yíng)商，版本，操作系統(tǒng)等。
• 業(yè)務(wù)層監(jiān)控，核心業(yè)務(wù)的監(jiān)控，例如：登錄，注冊(cè)，下單，支付等等。
• 應(yīng)用層監(jiān)控，相關(guān)的技術(shù)參數(shù)，例如：URL 請(qǐng)求次數(shù)，Service 請(qǐng)求數(shù)量，SQL 執(zhí)行的結(jié)果，Cache 的利用率，QPS 等等。
• 系統(tǒng)層監(jiān)控，物理主機(jī)，虛擬主機(jī)以及操作系統(tǒng)的參數(shù)。例如：CPU 利用率，內(nèi)存利用率，磁盤空間情況。
• 網(wǎng)絡(luò)層監(jiān)控，網(wǎng)絡(luò)情況參數(shù)。例如：網(wǎng)關(guān)流量情況，丟包率，錯(cuò)包率，連接數(shù)等等。

流行的監(jiān)控系統(tǒng)

前面講了監(jiān)控系統(tǒng)的功能，分類，分層，相信大家對(duì) IT 監(jiān)控系統(tǒng)都有一定的了解了。

接下來(lái)，我們來(lái)看看有哪些優(yōu)秀實(shí)踐。這里介紹兩個(gè)比較流行的監(jiān)控系統(tǒng)：

• Zabbix
• Prometheus

Zabbix

Zabbix 是一款企業(yè)級(jí)的分布式開(kāi)源監(jiān)控方案。它由 Alexei Vladishev 創(chuàng)建，由 Zabbix SIA 在持續(xù)開(kāi)發(fā)和支持。

Zabbix 能夠監(jiān)控網(wǎng)絡(luò)參數(shù)，服務(wù)器健康和軟件完整性。它提供通知機(jī)制，允許用戶配置告警，從而快速反饋問(wèn)題。

基于存儲(chǔ)的數(shù)據(jù)，Zabbix 提供報(bào)表和數(shù)據(jù)可視化，并且支持主動(dòng)輪詢和被動(dòng)捕獲。它的所有報(bào)告、統(tǒng)計(jì)信息和配置參數(shù)都可以通過(guò) Web 頁(yè)面訪問(wèn)。

Zabbix 的 API 功能，完善度很高，大部分操作都提供了 API 接口，方便和現(xiàn)有系統(tǒng)整合。

例如：通過(guò)歷史數(shù)據(jù)查詢 API，獲取線上服務(wù)器使用情況，生成報(bào)表;設(shè)置條件，對(duì)問(wèn)題服務(wù)器和問(wèn)題業(yè)務(wù)進(jìn)行篩選，加入告警。

利用 Zabbix graph 的 API，生成關(guān)鍵指標(biāo)趨勢(shì)圖，方便運(yùn)維人員實(shí)時(shí)了解系統(tǒng)情況。利用告警添加 API，讓監(jiān)控系統(tǒng)和部署系統(tǒng)聯(lián)動(dòng)。

比如新部署了一個(gè)新實(shí)例，那么自動(dòng)添加所需要的監(jiān)控策略;反之，下線一個(gè)實(shí)例，就刪除關(guān)聯(lián)的監(jiān)控策略。

Zabbix 由 Server，Agent，Proxy(可選項(xiàng))組成：

• Agent 負(fù)責(zé)收集數(shù)據(jù)，并且傳輸給 Server。
• Server 負(fù)責(zé)接受 Agent 的數(shù)據(jù)，進(jìn)行保存或者告警。
• Proxy 負(fù)責(zé)代理 Server 收集 Agent 傳輸?shù)臄?shù)據(jù)，并且轉(zhuǎn)發(fā)給 Server。Proxy 是安裝在被監(jiān)控的服務(wù)器上的，用來(lái)和 Server 端進(jìn)行通信，從而傳輸數(shù)據(jù)。

Zabbix 的部署模式

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

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

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

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

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

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

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

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

Prometheus(普羅米修斯)

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

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

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

一起來(lái)看看 Prometheus 的幾大組件：

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

Prometheus 架構(gòu)圖

說(shuō)完了 Prometheus 的組件，再來(lái)看看 Prometheus 的架構(gòu)：

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

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

Zabbix 和 Prometheus 比較圖

從上面的比較可以看出：

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

總結(jié)

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

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

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

因?yàn)橐獙?duì)整個(gè) 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)選擇使用。

---

閱讀目錄（置頂)(長(zhǎng)期更新計(jì)算機(jī)領(lǐng)域知識(shí)）https://blog.csdn.net/weixin_43392489/article/details/102380691

閱讀目錄（置頂)(長(zhǎng)期更新計(jì)算機(jī)領(lǐng)域知識(shí)）https://blog.csdn.net/weixin_43392489/article/details/102380882

總結(jié)

以上是生活随笔為你收集整理的第二十期：想吃透监控系统，就这一篇够不够?的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。