[[404126]]

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

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

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

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

• producer-metrics

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

• producer-node-metrics

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

• producer-topic-metrics

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

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

1.1 producer-metrics

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

其重點(diǎn)項(xiàng)說(shuō)明如下：

• batch-size-avg

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

• batch-size-max

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

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

• batch-split-rate

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

• batch-split-total

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

溫馨提示：按照筆者對(duì)這部分源碼的閱讀，我覺得ProducerBatch的split的意義不大，因?yàn)樾路峙涞腜roducerBatch的容量會(huì)等于batch.size，未超過(guò)該大小，則該Batch不會(huì)被分隔，筆者認(rèn)為該功能大概率無(wú)法完成實(shí)際的切割意圖。

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

• buffer-available-bytes

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

• buffer-total-bytes

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

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

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

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

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

• produce-throttle-time-avg

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

• produce-throttle-time-max

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

• io-ratio

IO線程處理IO讀寫的總時(shí)間

• io-time-ns-avg

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

• io-waittime-total

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

• iotime-total

io處理總時(shí)間。

• network-io-rate

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

• network-io-total

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

1.2 通用指標(biāo)

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

主要的維度說(shuō)明如下：

• producer-metics

發(fā)送端維度

• producer-node-metrics

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

• producer-topic-metrics

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

接下來(lái)說(shuō)明的指標(biāo)，分別以不同的維度進(jìn)行統(tǒng)計(jì)，但其表示的含義表示一樣，故接下來(lái)統(tǒng)一說(shuō)明。

• incoming-byte-rate

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

• incoming-byte-total

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

• outgoing-byte-total

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

• request-latency-avg

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

• request-latency-max

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

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

• request-rate

每秒發(fā)送Tps

• request-size-avg

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

• request-size-max

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

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

• request-total

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

• response-rate

每秒接受服務(wù)端響應(yīng)TPS

• response-total

收到服務(wù)端響應(yīng)總數(shù)量。

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

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

故為了更加直觀的展示這些指標(biāo)，因?yàn)樾枰〞r(shí)將這些信息進(jìn)行采集，統(tǒng)一存儲(chǔ)在其他數(shù)據(jù)庫(kù)等持久化存儲(chǔ)，可以根據(jù)歷史數(shù)據(jù)繪制曲線，希望實(shí)現(xiàn)的效果如下圖所示：

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

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

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