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

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

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

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

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

Kafka的主要概念

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

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

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

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

• Producer：消息生產(chǎn)者，負責發(fā)布消息到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: 生產(chǎn)者服務，匯報生產(chǎn)速率和生產(chǎn)可用性

• Consumer Service: 消費者服務，匯報消費速率和可用性、消息的延遲、丟失率和重復率

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

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

圖2 Kafka monitor 結構圖

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

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

圖3 Producer Service代碼解讀

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

• 消息序列號，用于在消費時檢查消息是否丟失或重復

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

• 消息的大小，用于指定序列化后的數(shù)據(jù)大?。ㄅ渲庙棧簆roduce.record.size.byte，默認值：100 byte）

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

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

圖4 Producer Service代碼解讀2

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

圖5 Consumer Service代碼解讀

Kakfa Monitor優(yōu)勢總結

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

這里需要注意的一點是：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ù)對消息的延遲、丟失率和重復率進行統(tǒng)計。

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

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

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

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

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

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

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

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

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

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

樣本覆蓋率

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

必要的流控

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

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

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

功能覆蓋率

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

超時處理

應對每個監(jiān)控請求設定超時時間，避免因服務響應慢導致請求堆積而影響服務。

盡量簡單

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