這篇文章給大家介紹從Kafka Monitor源碼解讀看如何做好黑盒監(jiān)控，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

創(chuàng)新互聯(lián)專業(yè)提供成都主機(jī)托管四川主機(jī)托管成都服務(wù)器托管四川服務(wù)器托管，支持按月付款！我們的承諾：貴族品質(zhì)、平民價格，機(jī)房位于中國電信/網(wǎng)通/移動機(jī)房，棕樹數(shù)據(jù)中心服務(wù)有保障！

首先帶來的是“監(jiān)控”專題系列。

眾所周知，監(jiān)控分為黑盒和白盒監(jiān)控，黑盒監(jiān)控是通過模擬外部用戶對其可見的系統(tǒng)功能進(jìn)行監(jiān)控的一種監(jiān)控方式。作為監(jiān)控的重要一環(huán)，黑盒監(jiān)控提供了讓系統(tǒng)或者服務(wù)在發(fā)生故障時能夠快速通知相關(guān)人員的能力。

通常情況下白盒監(jiān)控的數(shù)據(jù)來自服務(wù)或系統(tǒng)自身（例如CPU負(fù)載、堆棧信息、連接數(shù)······），所以易于采集。而相對而言，黑盒監(jiān)控的數(shù)據(jù)通常來自系統(tǒng)和服務(wù)外部，需要我們自己開發(fā)相關(guān)功能監(jiān)控模塊來完成采集。那么，黑盒監(jiān)控如何做？如何才能在及時發(fā)現(xiàn)服務(wù)故障的同時不會引起其它問題？

重點(diǎn)對Kafka Monitor監(jiān)控邏輯的部分代碼進(jìn)行解讀

下面將分享京東云在Kafka黑盒監(jiān)控方面的一些實(shí)踐經(jīng)驗(yàn)，其中著重對Kafka Monitor監(jiān)控邏輯的部分代碼進(jìn)行解讀，以便大家能夠?qū)ζ鋬?yōu)秀的設(shè)計(jì)有一個更為深入的了解。然后再結(jié)合我們在其它服務(wù)中的黑盒監(jiān)控實(shí)踐，來試圖回答上面提出的問題。enjoy：

Kafka Monitor介紹

Kafka Monitor是由Linkedin開源的一款非常優(yōu)秀的針對Kafka的黑盒監(jiān)控軟件。它通過模擬客戶端行為，生產(chǎn)和消費(fèi)數(shù)據(jù)并采集消息的延遲、錯誤率和重復(fù)率等性能和可用性指標(biāo)，來達(dá)到黑盒監(jiān)控的目的。

Kafka的主要概念

在介紹Kafka Monitor功能監(jiān)控之前，我們先了解下Kafka的幾個主要概念：

• Broker：Kafka集群包含一個或多個服務(wù)器，這種服務(wù)器被稱為broker

• Topic：每條發(fā)布到Kafka集群的消息都有一個類別，這個類別被稱為Topic。物理上不同Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存于一個或多個broker上，但用戶只需指定消息的Topic即可生產(chǎn)或消費(fèi)數(shù)據(jù)而不必關(guān)心數(shù)據(jù)存于何處

• Partition：Partition是物理上的概念，每個Topic包含一個或多個Partition

• Producer：消息生產(chǎn)者，負(fù)責(zé)發(fā)布消息到Kafka broker的客戶端

• Consumer：消息消費(fèi)者，讀取Kafka broker消息的客戶端

• Consumer Group：消費(fèi)者組，每個Consumer屬于一個特定的Consumer Group

圖1 Kafka架構(gòu)圖

Kafka Monitor模塊組成

1.kafka Monitor由以下五個服務(wù)組成

• Jetty Service：提供用于Web UI展示的HTTP服務(wù)

• Jolokia Service：提供JMX的HTTP接口

• Produce Service: 生產(chǎn)者服務(wù)，匯報(bào)生產(chǎn)速率和生產(chǎn)可用性

• Consumer Service: 消費(fèi)者服務(wù)，匯報(bào)消費(fèi)速率和可用性、消息的延遲、丟失率和重復(fù)率

• Metrics Service：接受Produce Service和Consumer Service匯報(bào)的監(jiān)控指標(biāo)

2.各服務(wù)之間的結(jié)構(gòu)圖如下

圖2 Kafka monitor 結(jié)構(gòu)圖

監(jiān)控工作流程及代碼解讀

1.Producer Service啟動后以一定的時間為周期（配置項(xiàng)：produce.record.delay.ms，默認(rèn)值：100ms）生產(chǎn)數(shù)據(jù)。需要注意的是，Producer Service會為每個Partition啟動一個單獨(dú)的生產(chǎn)任務(wù)，目的是為了讓每個周期內(nèi)生產(chǎn)的數(shù)據(jù)能夠覆蓋到所有Partition上。

圖3 Producer Service代碼解讀

2. 每條消息由以下內(nèi)容組成：

• 消息序列號，用于在消費(fèi)時檢查消息是否丟失或重復(fù)

• 時間戳，用于計(jì)算消息從生產(chǎn)到消費(fèi)的時延

• 消息的大小，用于指定序列化后的數(shù)據(jù)大小（配置項(xiàng)：produce.record.size.byte，默認(rèn)值：100 byte）

• Topic和Producer ID，用于確保消費(fèi)到的數(shù)據(jù)是來自同一Topic和Producer

每條消息序列化后提交到Kafka的指定Topic上，然后通過_sensors對象匯報(bào)失敗或成功狀態(tài)

圖4 Producer Service代碼解讀2

3.Consumer Service從指定Topic消費(fèi)讀取消息，每條消息經(jīng)過反序列化和校驗(yàn)后，計(jì)算出消息的延遲、錯誤或重復(fù)等監(jiān)控指標(biāo)，通過_sensors對象匯報(bào)到Metrics Service。

圖5 Consumer Service代碼解讀

Kakfa Monitor優(yōu)勢總結(jié)

1.通過為每個Partition啟動單獨(dú)的生產(chǎn)任務(wù)，確保監(jiān)控覆蓋所有Partition。

這里需要注意的一點(diǎn)是：Kafka Monitor僅能夠保證監(jiān)控覆蓋所有Partition，但不能保證覆蓋所有Broker。所以，為保證監(jiān)控覆蓋所有Broker，利用Kafka對Partition在Broker的均衡分配原則，我們需要為Kafka Monitor的Topic配置與Broker相同（或整數(shù)倍）數(shù)量的Partition。

2.在生產(chǎn)的消息中包含了時間戳、序列號，Kafka Monitor可以依據(jù)這些數(shù)據(jù)對消息的延遲、丟失率和重復(fù)率進(jìn)行統(tǒng)計(jì)。

3.通過設(shè)定消息生成的頻率，來達(dá)到控制流量的目的。

4.生產(chǎn)的消息在序列化時指定為一個可配置的大小，這樣做的好處有：

• 便于通過可配置的消息長度來驗(yàn)證Kafka對不同大小數(shù)據(jù)的處理能力

• 相同的消息大小可以減少Kafka對因每次處理不同大小數(shù)據(jù)的性能不均帶來的監(jiān)控誤差

5.通過設(shè)定單獨(dú)的Topic和Producer ID來操作Kafka集群，可避免污染線上數(shù)據(jù)，做到一定程度上的數(shù)據(jù)隔離。

如何做黑盒監(jiān)控

通過上面的內(nèi)容，相信大家對Kafka Monitor的黑盒監(jiān)控實(shí)現(xiàn)方式有了一定認(rèn)識。結(jié)合我們在做黑盒監(jiān)控工作實(shí)踐中遇到的問題，大致總結(jié)出黑盒監(jiān)控需要注意的事項(xiàng)以及一些建議：

監(jiān)控指標(biāo)的采集

黑盒監(jiān)控所采集的監(jiān)控指標(biāo)主要有兩大類：性能和可用性，這兩類監(jiān)控項(xiàng)的采集可參考以下建議：

• 在讀寫類操作中，通過在消息體中攜帶Timestamp進(jìn)行延時監(jiān)控

• 使用固定字符串進(jìn)行語義正確性的監(jiān)控，避免僅僅針對返回的狀態(tài)碼來判斷

樣本覆蓋率

黑盒監(jiān)控的采集樣本應(yīng)盡可能覆蓋所有節(jié)點(diǎn)，以便能夠及時發(fā)現(xiàn)因節(jié)點(diǎn)宕機(jī)引起的故障。樣本覆蓋率應(yīng)該是可以采集并可量化的。在實(shí)踐中，我們建議在監(jiān)控樣本的請求中攜帶特定的可在服務(wù)端節(jié)點(diǎn)上識別的標(biāo)簽（可以是特定的源IP、用戶名、請求頭等等），這樣便于統(tǒng)計(jì)樣本覆蓋率。

必要的流控

黑盒監(jiān)控不是壓力測試，應(yīng)該避免過高的流量對線上服務(wù)產(chǎn)生沖擊。必要時，流控的設(shè)定需要結(jié)合節(jié)點(diǎn)覆蓋率和功能覆蓋率兩個指標(biāo)進(jìn)行。例如，我們在Zookeeper的黑盒監(jiān)控實(shí)踐中，考慮到Zookeeper的讀寫邏輯不同，承受的壓力上限也不同，所以我們需要分別對讀和寫兩個功能設(shè)定不同的監(jiān)控樣本數(shù)，這樣就能夠讓兩種功能的監(jiān)控樣本既能滿足樣本覆蓋率，又不會對線上服務(wù)產(chǎn)生沖擊。

數(shù)據(jù)隔離

受其特點(diǎn)決定，黑盒監(jiān)控直接模擬用戶行為對線上服務(wù)進(jìn)行讀寫操作，所以必要的數(shù)據(jù)隔離是非常有必要的。具體的隔離方法需要視不同業(yè)務(wù)場景而定。例如，在HDFS的黑盒監(jiān)控實(shí)踐中，我們使用單獨(dú)的與業(yè)務(wù)隔離的非特權(quán)賬號，在指定的路徑下讀寫數(shù)據(jù)。

功能覆蓋率

黑盒監(jiān)控應(yīng)盡量覆蓋所有（重要的）功能場景。此項(xiàng)需要我們對服務(wù)和線上使用場景有比較充分的了解。

超時處理

應(yīng)對每個監(jiān)控請求設(shè)定超時時間，避免因服務(wù)響應(yīng)慢導(dǎo)致請求堆積而影響服務(wù)。

盡量簡單

黑盒監(jiān)控的實(shí)現(xiàn)邏輯應(yīng)該在充分模擬外部用戶行為的同時盡量簡單，并減少對外部服務(wù)的依賴，這樣可以降低因依賴方或監(jiān)控本身的問題導(dǎo)致的監(jiān)控?cái)?shù)據(jù)異常。

關(guān)于從Kafka Monitor源碼解讀看如何做好黑盒監(jiān)控就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。

分享標(biāo)題：從KafkaMonitor源碼解讀看如何做好黑盒監(jiān)控-創(chuàng)新互聯(lián)
鏈接URL：http://jinyejixie.com/article26/ggdjg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、網(wǎng)站收錄、網(wǎng)站營銷、搜索引擎優(yōu)化、網(wǎng)站排名、企業(yè)建站

廣告

聲明：本網(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)