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

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

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

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

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

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

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

Kafka Monitor介紹

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

Kafka的主要概念

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

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

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

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

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

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

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

圖1 Kafka架構(gòu)圖

Kafka Monitor模塊組成

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

圖3 Producer Service代碼解讀

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

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

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

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

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

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

圖4 Producer Service代碼解讀2

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

圖5 Consumer Service代碼解讀

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

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

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

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

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

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

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

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

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

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

通過上面的內(nèi)容，相信大家對(duì)Kafka Monitor的黑盒監(jiān)控實(shí)現(xiàn)方式有了一定認(rèn)識(shí)。結(jié)合我們?cè)谧龊诤斜O(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)行延時(shí)監(jiān)控

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

樣本覆蓋率

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

必要的流控

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

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

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

功能覆蓋率

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

超時(shí)處理

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

盡量簡(jiǎn)單

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

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

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

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

廣告

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