[[404126]]

在Kafka消息發(fā)送端遇到性能瓶頸時是否有辦法正確的評估瓶頸在哪呢?如何針對性的進行調(diào)優(yōu)呢?

1、Kafka 消息發(fā)送端監(jiān)控指標

其實Kafka早就為我們考慮好了，Kafka提供了豐富的監(jiān)控指標，并提供了JMX的方式來獲取這些監(jiān)控指標，在客戶端提供的監(jiān)控指標如下圖所示：

主要的監(jiān)控指標分類如下：

• producer-metrics

消息發(fā)送端的監(jiān)控指標，其子節(jié)點為該進程下所有的生產(chǎn)者

• producer-node-metrics

以Broker節(jié)點為維度，每一個發(fā)送方的數(shù)據(jù)指標。

• producer-topic-metrics

以topic為維度，統(tǒng)計該發(fā)送端的一些指標。

Kafka Producer相關(guān)的指標比較多，本文不會一一羅列。

1.1 producer-metrics

producer-metrics是發(fā)送端一個非常重要的監(jiān)控項，如下圖所示：

其重點項說明如下：

• batch-size-avg

Sender線程實際發(fā)送消息時一個批次(ProducerBatch)的平均大小。

• batch-size-max

Sender線程時間發(fā)送消息時一個批次的最大大小。

實踐指導：個人覺得這兩個參數(shù)非常有必要進行采集，如果該值遠小于batch.size設置的值，如果吞吐量不達預期，可以適當調(diào)大linger.ms。

• batch-split-rate

Kafka提供了對大的ProducerBatch分割成小的機制，即如果客戶端的ProducerBatch如果超過了服務端允許的最大消息大小，將會觸發(fā)在客戶端分割重新發(fā)送，該值記錄每秒切割的速率

• batch-split-total

Kafka 發(fā)生的 split 次數(shù)。

溫馨提示：按照筆者對這部分源碼的閱讀，我覺得ProducerBatch的split的意義不大，因為新分配的ProducerBatch的容量會等于batch.size，未超過該大小，則該Batch不會被分隔，筆者認為該功能大概率無法完成實際的切割意圖。

實踐指導：如果該值不為0，則表示服務端，客戶端設置的消息大小不合理，客戶端設置的batch.szie大小應該小于服務端設置的 max.message.bytes，默認值100W字節(jié)(約等于1M)

• buffer-available-bytes

當前發(fā)送端緩存區(qū)可用字節(jié)大小。

• buffer-total-bytes

發(fā)送端總的緩存區(qū)大小，默認為32M，33,554,432個字節(jié)。

實戰(zhàn)指導：如果緩存區(qū)剩余字節(jié)數(shù)持續(xù)較低，需要評估緩存區(qū)大小是否合適，Sender線程遇到了瓶頸，從而考慮網(wǎng)絡、Brorker是否遇到瓶頸。

• bufferpool-wait-ratio
• bufferpool-wait-time-total

客戶端從緩存區(qū)中申請內(nèi)存用于創(chuàng)建ProducerBatch所阻塞的總時長。

實戰(zhàn)指導：如果該值持續(xù)大于0，說明發(fā)送存在瓶頸，可以適當降低linger.ms的值，讓消息有機會得到更加及時的處理。

• produce-throttle-time-avg

消息發(fā)送被broker限流的平均時間

• produce-throttle-time-max

消息發(fā)送被broker限流的最大時間

• io-ratio

IO線程處理IO讀寫的總時間

• io-time-ns-avg

每一次事件選擇器調(diào)用IO操作的平均時間(單位為納秒)

• io-waittime-total

io線程等待讀寫就緒的平均時間(單位為納秒)

• iotime-total

io處理總時間。

• network-io-rate

客戶端每秒所有連接的網(wǎng)絡讀寫tps。

• network-io-total

客戶端所有連接上的網(wǎng)絡操作(讀或?qū)?總數(shù)。

1.2 通用指標

Kafka在消息發(fā)送端除了上述指標外，還有一些通用類的監(jiān)控指標，這類指標的統(tǒng)計維度包括：消息發(fā)送者、節(jié)點、TOPIC三個維度。

主要的維度說明如下：

• producer-metics

發(fā)送端維度

• producer-node-metrics

發(fā)送端-Broker節(jié)點維度

• producer-topic-metrics

發(fā)送端-主題維度的統(tǒng)計

接下來說明的指標，分別以不同的維度進行統(tǒng)計，但其表示的含義表示一樣，故接下來統(tǒng)一說明。

• incoming-byte-rate

每秒的入端流量，每秒進入的字節(jié)數(shù)。

• incoming-byte-total

總共進入的字節(jié)數(shù)。

• outgoing-byte-total

總出發(fā)送的字節(jié)數(shù)。

• request-latency-avg

消息發(fā)送的平均延時。

• request-latency-max

消息發(fā)送的最大延遲時間。

實戰(zhàn)指導：latency-avg與max可以反應消息發(fā)送的延遲性能，如果延遲過高，說明Sender線程發(fā)送消息存在瓶頸，建議該值與linger.ms進行比較，如果該值顯著小于linger.ms，則為了提高吞吐率，可適當調(diào)整batch.size的大小。

• request-rate

每秒發(fā)送Tps

• request-size-avg

消息發(fā)送的平均大小。

• request-size-max

Sender線程單次消息發(fā)送的最大大小。

實戰(zhàn)指導：如果該值遲遲小于max.request.size，說明客戶端消息積壓的消息不多，如果從其他維度表明遇到了瓶頸，可以適當linger.ms，batch.size，可有效提高吞吐。

• request-total

請求發(fā)送的總字節(jié)數(shù)

• response-rate

每秒接受服務端響應TPS

• response-total

收到服務端響應總數(shù)量。

2、監(jiān)控指標采集

雖然Kafka內(nèi)置了眾多的監(jiān)控指標，但這些指標默認是存儲在內(nèi)存中，既然是存放在內(nèi)存中，為了避免監(jiān)控數(shù)據(jù)無休止的增加內(nèi)存觸發(fā)內(nèi)存溢出，通常監(jiān)控數(shù)據(jù)的存儲基本是基于滑動窗口，即只會存儲最近一段時間內(nèi)的監(jiān)控數(shù)據(jù)，進行滾動覆蓋。

故為了更加直觀的展示這些指標，因為需要定時將這些信息進行采集，統(tǒng)一存儲在其他數(shù)據(jù)庫等持久化存儲，可以根據(jù)歷史數(shù)據(jù)繪制曲線，希望實現(xiàn)的效果如下圖所示：

基本的監(jiān)控采集系統(tǒng)架構(gòu)設計如下圖所示：

mq-collect應該是放在生產(chǎn)者SDK中，通過mq-collect類庫異步定時將采集信息上傳的到時序數(shù)據(jù)庫InfluxDB,然后通過mq-portal門戶展示頁面，對每一個生產(chǎn)客戶端按指標進行可視化展示，實現(xiàn)監(jiān)控數(shù)據(jù)的可視化，從而為性能優(yōu)化提供依據(jù)。

本文轉(zhuǎn)載自微信公眾號「中間件興趣圈」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系中間件興趣圈公眾號。