[[413084]]

作為Kafka集群的負(fù)責(zé)人，消費(fèi)端出現(xiàn)消息積壓，反復(fù)發(fā)生重平衡等問題時(shí)，如何快速定位性能瓶頸顯的至關(guān)重要。

本篇將詳細(xì)介紹消費(fèi)端端監(jiān)控指標(biāo)，讓架構(gòu)師提出的性能優(yōu)化方案提供數(shù)據(jù)支撐。

Kafka的設(shè)計(jì)者早就為我們考慮好了，提供了豐富多彩的監(jiān)控指標(biāo)。

1、消費(fèi)端指標(biāo)

Kafka中的監(jiān)控指標(biāo)通過MBean進(jìn)行存儲(chǔ)，我們可以通過jconsole中進(jìn)行查看，截圖如下：

主要分為如下四個(gè)維度展開：

• Consumer-coordinator-metrics

消費(fèi)者組協(xié)調(diào)器相關(guān)的監(jiān)控指標(biāo)。

• Consumer-fetch-manager-metrics

消費(fèi)組消息拉取相關(guān)的監(jiān)控指標(biāo)

• Consumer-node-metrics

以broker節(jié)點(diǎn)為維度的統(tǒng)計(jì)信息，消費(fèi)端向多個(gè)broker節(jié)點(diǎn)拉取消息等監(jiān)控指標(biāo)。

• Kafka-metrics-count

接下來將分別展開，詳細(xì)介紹其各個(gè)指標(biāo)的含義，并給出一些實(shí)踐指導(dǎo)。

1.1 消費(fèi)者組協(xié)調(diào)器監(jiān)控指標(biāo)

組協(xié)調(diào)器相關(guān)的監(jiān)控指標(biāo)明細(xì)說明如下：

詳細(xì)說明如下：

• join-time-max

消費(fèi)者重新加入消費(fèi)組的最大時(shí)長

• join-time-avg

消費(fèi)者重新加入消費(fèi)組的平均時(shí)長

• join-rate

消費(fèi)者加入消費(fèi)組的TPS

實(shí)踐指導(dǎo)：該值為0正常，該值越大，越有問題，說明消費(fèi)者在頻繁加入消費(fèi)者，在加入消費(fèi)者的過程中消費(fèi)者是不會(huì)消費(fèi)消息的。

• join-time-avg

消費(fèi)者加入消費(fèi)組的平均時(shí)間

• join-total

該消費(fèi)者重新加入消費(fèi)組的次數(shù)(重平衡發(fā)生的次數(shù))

實(shí)踐指導(dǎo)：該值值的采集，如果該值過大，說明發(fā)生重平衡的次數(shù)太多，重平衡時(shí)該消費(fèi)者時(shí)不參與消息消費(fèi)。

• commit-latency-avg

提交位點(diǎn)的平均耗時(shí)

• commit-rate

提交位點(diǎn)的tps

• commit-latency-max

提交位點(diǎn)時(shí)的最大延遲時(shí)間

• commit-total

消費(fèi)者啟動(dòng)以來的位點(diǎn)提交的總次數(shù)

• sync-time-avg

消費(fèi)者發(fā)送sync的平均響應(yīng)時(shí)長。

知識(shí)點(diǎn)：消費(fèi)者加入小組后由該消費(fèi)者中的Leader負(fù)責(zé)進(jìn)行隊(duì)列分配，然后將分配方案發(fā)送給組協(xié)議器，各個(gè)從節(jié)點(diǎn)將向組協(xié)調(diào)器獲取分配隊(duì)列。

• sync-rate

消費(fèi)者發(fā)送sync的tps

• sync-total

消費(fèi)者發(fā)送sync請求的總次數(shù)

• sync-time-max

消費(fèi)者sync請求響應(yīng)的最大響應(yīng)時(shí)間

• assigned-partitions

當(dāng)前分配到的分區(qū)數(shù)量

• heartbeat-total

心跳請求的總數(shù)

• heartbeat-response-time-max

心跳請求的最大響應(yīng)時(shí)間

• last-heartbeat-seconds-ago

上一次發(fā)送心跳包的時(shí)間

• heartbeat-rate

發(fā)送心跳包的tps

從監(jiān)控指標(biāo)來看，我們有能得知消費(fèi)端協(xié)調(diào)器的職責(zé)：

• 協(xié)調(diào)消費(fèi)者加入消費(fèi)組
• 協(xié)調(diào)消費(fèi)者Leader進(jìn)行隊(duì)列負(fù)載分配
• 發(fā)送心跳，保持會(huì)話
• 提交位點(diǎn)

1.2 消費(fèi)者消息拉取監(jiān)控指標(biāo)

消費(fèi)者與消息拉取相關(guān)的監(jiān)控指標(biāo)如下圖所示：

 

消費(fèi)組拉取指標(biāo)的組織分成消費(fèi)組與該消費(fèi)組訂閱的多個(gè)topic兩個(gè)維度。

接下來詳細(xì)分析上述指標(biāo)：

• bytes-consumed-rate

消費(fèi)端每秒提交到業(yè)務(wù)的tps。

• bytes-consumed-total

消費(fèi)端目前消費(fèi)的總字節(jié)數(shù)。

• fetch-latency-max

API.FETCH請求(即向broker端發(fā)送消息拉取)的最大耗時(shí)。

• records-per-request-avg

每一次Fetch請求拉取的消息條數(shù)(對(duì)當(dāng)前指標(biāo)取平均值)。

• fetch-rate

客戶端發(fā)送Fetch請求的tps。

• fetch-total

客戶端總共發(fā)起的Fetch請求個(gè)數(shù)

• fetch-throttle-time-max

消息拉取(Fetch請求)由于服務(wù)端(broker)限流的最大限流時(shí)長，關(guān)于broker端限流機(jī)制，后續(xù)會(huì)重點(diǎn)探究。

• fetch-throttle-time-avg

消息拉取Fetch請求的平均限流時(shí)長。

• fetch-size-max

單個(gè)分區(qū)一次消息拉取最大的字節(jié)數(shù)。

實(shí)踐指導(dǎo)：該值非常有必要采集監(jiān)控，可以評(píng)估消費(fèi)端消息的拉取能力，如果該值持續(xù)接近設(shè)置的期望值，如果消費(fèi)端tps不滿足需求，可以適當(dāng)調(diào)大該值。

• fetch-latency-avg

消息拉取的平均耗時(shí)。

• fetch-size-avg

一次消息拉取的平均字節(jié)數(shù)

• records-consumed-total

消費(fèi)端消費(fèi)端總字節(jié)數(shù)

• records-lead-min

當(dāng)前消費(fèi)位點(diǎn)與日志端中最小位點(diǎn)的差值。

• records-lag-max

分配給消費(fèi)者的分區(qū)中，消息積壓的最大值。

實(shí)戰(zhàn)指導(dǎo)：可以基于該值做告警。

消費(fèi)者還會(huì)從主題-分區(qū)級(jí)別采集與消費(fèi)進(jìn)度相關(guān)的指標(biāo)，相關(guān)指標(biāo)說明如下：

• records-lag
• records-lag-avg
• records-lag-max
• records-lead
• records-lead-avg
• records-lead-min

對(duì)于上述指標(biāo)，主要是解釋一下兩個(gè)基本的含義，其他指標(biāo)是對(duì)其進(jìn)行聚合計(jì)算(max,avg)。

• records-lag

消費(fèi)積壓，即消費(fèi)位點(diǎn)與當(dāng)前分區(qū)最大位點(diǎn)點(diǎn)差距，該值越大，說明消費(fèi)端處理速度越慢，需要十分關(guān)注，通常需要接入告警，及時(shí)通知項(xiàng)目方。

• records-lead

消費(fèi)位點(diǎn)與當(dāng)前分區(qū)最小位點(diǎn)的差距，我對(duì)該值的具體用途暫未參悟，有心的讀者看到，歡迎與我共同交流。

1.3 消費(fèi)者網(wǎng)絡(luò)相關(guān)監(jiān)控指標(biāo)

上面的指標(biāo)主要是關(guān)注消費(fèi)端協(xié)調(diào)器、消費(fèi)端Fetch(消息拉取)兩個(gè)重要維度，接下來關(guān)注一下從消息者的視角關(guān)注一下底層網(wǎng)絡(luò)IO等維度相關(guān)的指標(biāo)，相關(guān)指標(biāo)的采集入口位Kafka的org.apache.kafka.common.network.Selector,其具體的指標(biāo)如下圖所示：

其實(shí)這些指標(biāo)基本與生產(chǎn)者相同，說明如下：

• request-rate

請求發(fā)送tps。

• request-size-max

請求發(fā)送的最大字節(jié)

• request-size-avg

請求的平均大小

• request-total

總共的請求個(gè)數(shù)

• select-rate

事件選擇器tps。

• select-total

事件選擇器執(zhí)行事件選擇的總次數(shù)

• response-total

響應(yīng)請求總數(shù)

• response-rate

響應(yīng)TPS

• outgoing-byte-rate

每秒發(fā)送字節(jié)數(shù)

• outgoing-byte-total

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

• incoming-byte-rate

每秒接受字節(jié)數(shù)

• incoming-byte-total

總工接受字節(jié)數(shù)

• io-ratio

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

• io-time-ns-avg

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

• io-waittime-total

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

• iotime-total

io處理總時(shí)間。

• io-wait-ratio

io等待占io總處理時(shí)間的比例

• io-wait-time-ns-avg

io線程平均等待時(shí)間(納秒)

實(shí)戰(zhàn)指導(dǎo)：網(wǎng)絡(luò)相關(guān)的監(jiān)控指標(biāo)，可以重點(diǎn)關(guān)注一下io線程相關(guān)的性能。

1.4 按broker節(jié)點(diǎn)采集監(jiān)控?cái)?shù)據(jù)

客戶端還會(huì)按照broker的維度，重點(diǎn)采集與請求相關(guān)的指標(biāo)，例如請求tps、平均響應(yīng)時(shí)間。

實(shí)戰(zhàn)指導(dǎo)：監(jiān)控指標(biāo)的含義都已經(jīng)在上文中提到過，這些指標(biāo)應(yīng)該是最值得采集，特別是request-latency-max、request-latency-avg，這對(duì)確認(rèn)broker是否存在瓶頸。

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ù)無休止的增加內(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ù)庫等持久化存儲(chǔ)，可以根據(jù)歷史數(shù)據(jù)繪制曲線，希望實(shí)現(xiàn)的效果如下圖所示：

在這里插入圖片描述

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

mq-collect應(yīng)該是放在生產(chǎn)者SDK中，通過mq-collect類庫異步定時(shí)將采集信息上傳的到時(shí)序數(shù)據(jù)庫InfluxDB,然后通過mq-portal門戶展示頁面，對(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ān)注。轉(zhuǎn)載本文請聯(lián)系中間件興趣圈公眾號(hào)。