1. 程式人生 > >以小見大,從Kafka Monitor原始碼解讀看如何做好黑盒監控

以小見大,從Kafka Monitor原始碼解讀看如何做好黑盒監控

Kafka Monitor介紹

 

Kafka Monitor是由Linkedin開源的一款非常優秀的針對Kafka的黑盒監控軟體。它通過模擬客戶端行為,生產和消費資料並採集訊息的延遲、錯誤率和重複率等效能和可用性指標,來達到黑盒監控的目的。

 

Kafka的主要概念

 

在介紹Kafka Monitor功能監控之前,我們先了解下Kafka的幾個主要概念:

 

  • Broker:Kafka叢集包含一個或多個伺服器,這種伺服器被稱為broker

  • Topic:每條釋出到Kafka叢集的訊息都有一個類別,這個類別被稱為Topic。物理上不同Topic的訊息分開儲存,邏輯上一個Topic的訊息雖然保存於一個或多個broker上,但使用者只需指定訊息的Topic即可生產或消費資料而不必關心資料存於何處

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

  • Producer:訊息生產者,負責釋出訊息到Kafka broker的客戶端

  • Consumer:訊息消費者,讀取Kafka broker訊息的客戶端

  • Consumer Group:消費者組,每個Consumer屬於一個特定的Consumer Group

 

圖1 Kafka架構圖

 

Kafka Monitor模組組成

 

1.kafka Monitor由以下五個服務組成

  • Jetty Service:提供用於Web UI展示的HTTP服務

  • Jolokia Service:提供JMX的HTTP介面

  • Produce Service: 生產者服務,彙報生產速率和生產可用性

  • Consumer Service: 消費者服務,彙報消費速率和可用性、訊息的延遲、丟失率和重複率

  • Metrics Service:接受Produce Service和Consumer Service彙報的監控指標

 

2.各服務之間的結構圖如下

圖2 Kafka monitor 結構圖

 

監控工作流程及程式碼解讀

 

1.Producer Service啟動後以一定的時間為週期(配置項:produce.record.delay.ms,預設值:100ms)生產資料。需要注意的是,Producer Service會為每個Partition啟動一個單獨的生產任務,目的是為了讓每個週期內生產的資料能夠覆蓋到所有Partition上。

 

圖3 Producer Service程式碼解讀

 

2. 每條訊息由以下內容組成:

  • 訊息序列號,用於在消費時檢查訊息是否丟失或重複

  • 時間戳,用於計算訊息從生產到消費的時延

  • 訊息的大小,用於指定序列化後的資料大小(配置項:produce.record.size.byte,預設值:100 byte)

  • Topic和Producer ID,用於確保消費到的資料是來自同一Topic和Producer

每條訊息序列化後提交到Kafka的指定Topic上,然後通過_sensors物件彙報失敗或成功狀態

 

圖4 Producer Service程式碼解讀2

 

3.Consumer Service從指定Topic消費讀取訊息,每條訊息經過反序列化和校驗後,計算出訊息的延遲、錯誤或重複等監控指標,通過_sensors物件彙報到Metrics Service。

 

圖5 Consumer Service程式碼解讀

 

Kakfa Monitor優勢總結

 

1.通過為每個Partition啟動單獨的生產任務,確保監控覆蓋所有Partition。

 

這裡需要注意的一點是:Kafka Monitor僅能夠保證監控覆蓋所有Partition,但不能保證覆蓋所有Broker。所以,為保證監控覆蓋所有Broker,利用Kafka對Partition在Broker的均衡分配原則,我們需要為Kafka Monitor的Topic配置與Broker相同(或整數倍)數量的Partition。

 

2.在生產的訊息中包含了時間戳、序列號,Kafka Monitor可以依據這些資料對訊息的延遲、丟失率和重複率進行統計。

 

3.通過設定訊息生成的頻率,來達到控制流量的目的。

 

4.生產的訊息在序列化時指定為一個可配置的大小,這樣做的好處有:

  • 便於通過可配置的訊息長度來驗證Kafka對不同大小資料的處理能力

  • 相同的訊息大小可以減少Kafka對因每次處理不同大小資料的效能不均帶來的監控誤差

 

5.通過設定單獨的Topic和Producer ID來操作Kafka叢集,可避免汙染線上資料,做到一定程度上的資料隔離。

 

如何做黑盒監控

 

通過上面的內容,相信大家對Kafka Monitor的黑盒監控實現方式有了一定認識。結合我們在做黑盒監控工作實踐中遇到的問題,大致總結出黑盒監控需要注意的事項以及一些建議:

 

監控指標的採集

 

黑盒監控所採集的監控指標主要有兩大類:效能和可用性,這兩類監控項的採集可參考以下建議:

  • 在讀寫類操作中,通過在訊息體中攜帶Timestamp進行延時監控

  • 使用固定字串進行語義正確性的監控,避免僅僅針對返回的狀態碼來判斷

 

樣本覆蓋率

 

黑盒監控的採集樣本應儘可能覆蓋所有節點,以便能夠及時發現因節點宕機引起的故障。樣本覆蓋率應該是可以採集並可量化的。在實踐中,我們建議在監控樣本的請求中攜帶特定的可在服務端節點上識別的標籤(可以是特定的源IP、使用者名稱、請求頭等等),這樣便於統計樣本覆蓋率。

 

必要的流控

 

黑盒監控不是壓力測試,應該避免過高的流量對線上服務產生衝擊。必要時,流控的設定需要結合節點覆蓋率和功能覆蓋率兩個指標進行。例如,我們在Zookeeper的黑盒監控實踐中,考慮到Zookeeper的讀寫邏輯不同,承受的壓力上限也不同,所以我們需要分別對讀和寫兩個功能設定不同的監控樣本數,這樣就能夠讓兩種功能的監控樣本既能滿足樣本覆蓋率,又不會對線上服務產生衝擊。

 

資料隔離

 

受其特點決定,黑盒監控直接模擬使用者行為對線上服務進行讀寫操作,所以必要的資料隔離是非常有必要的。具體的隔離方法需要視不同業務場景而定。例如,在HDFS的黑盒監控實踐中,我們使用單獨的與業務隔離的非特權賬號,在指定的路徑下讀寫資料。

 

功能覆蓋率

 

黑盒監控應儘量覆蓋所有(重要的)功能場景。此項需要我們對服務和線上使用場景有比較充分的瞭解。

 

超時處理

 

應對每個監控請求設定超時時間,避免因服務響應慢導致請求堆積而影響服務。

 

儘量簡單

黑盒監控的實現邏輯應該在充分模擬外部使用者行為的同時儘量簡單,並減少對外部服務的依賴,這樣可以降低因依賴方或監控本身的問題導致的監控資料異常。