從KafkaMonitor源碼解讀看如何做好黑盒監(jiān)控-創(chuàng)新互聯(lián)

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

創(chuàng)新互聯(lián)專業(yè)提供成都主機(jī)托管四川主機(jī)托管成都服務(wù)器托管四川服務(wù)器托管,支持按月付款!我們的承諾:貴族品質(zhì)、平民價(jià)格,機(jī)房位于中國電信/網(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

從Kafka Monitor源碼解讀看如何做好黑盒監(jiān)控

圖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)圖如下

從Kafka Monitor源碼解讀看如何做好黑盒監(jiān)控

圖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上。

從Kafka Monitor源碼解讀看如何做好黑盒監(jiān)控

圖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)

從Kafka Monitor源碼解讀看如何做好黑盒監(jiān)控

圖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。

從Kafka Monitor源碼解讀看如何做好黑盒監(jiān)控

圖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)行語義正確性的監(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://bm7419.com/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)

成都網(wǎng)站建設(shè)公司