[[413084]]

作為Kafka集群的負責人，消費端出現消息積壓，反復發生重平衡等問題時，如何快速定位性能瓶頸顯的至關重要。

本篇將詳細介紹消費端端監控指標，讓架構師提出的性能優化方案提供數據支撐。

Kafka的設計者早就為我們考慮好了，提供了豐富多彩的監控指標。

1、消費端指標

Kafka中的監控指標通過MBean進行存儲，我們可以通過jconsole中進行查看，截圖如下：

主要分為如下四個維度展開：

• Consumer-coordinator-metrics

消費者組協調器相關的監控指標。

• Consumer-fetch-manager-metrics

消費組消息拉取相關的監控指標

• Consumer-node-metrics

以broker節點為維度的統計信息，消費端向多個broker節點拉取消息等監控指標。

• Kafka-metrics-count

接下來將分別展開，詳細介紹其各個指標的含義，并給出一些實踐指導。

1.1 消費者組協調器監控指標

組協調器相關的監控指標明細說明如下：

詳細說明如下：

• join-time-max

消費者重新加入消費組的最大時長

• join-time-avg

消費者重新加入消費組的平均時長

• join-rate

消費者加入消費組的TPS

實踐指導：該值為0正常，該值越大，越有問題，說明消費者在頻繁加入消費者，在加入消費者的過程中消費者是不會消費消息的。

• join-time-avg

消費者加入消費組的平均時間

• join-total

該消費者重新加入消費組的次數(重平衡發生的次數)

實踐指導：該值值的采集，如果該值過大，說明發生重平衡的次數太多，重平衡時該消費者時不參與消息消費。

• commit-latency-avg

提交位點的平均耗時

• commit-rate

提交位點的tps

• commit-latency-max

提交位點時的最大延遲時間

• commit-total

消費者啟動以來的位點提交的總次數

• sync-time-avg

消費者發送sync的平均響應時長。

知識點：消費者加入小組后由該消費者中的Leader負責進行隊列分配，然后將分配方案發送給組協議器，各個從節點將向組協調器獲取分配隊列。

• sync-rate

消費者發送sync的tps

• sync-total

消費者發送sync請求的總次數

• sync-time-max

消費者sync請求響應的最大響應時間

• assigned-partitions

當前分配到的分區數量

• heartbeat-total

心跳請求的總數

• heartbeat-response-time-max

心跳請求的最大響應時間

• last-heartbeat-seconds-ago

上一次發送心跳包的時間

• heartbeat-rate

發送心跳包的tps

從監控指標來看，我們有能得知消費端協調器的職責：

• 協調消費者加入消費組
• 協調消費者Leader進行隊列負載分配
• 發送心跳，保持會話
• 提交位點

1.2 消費者消息拉取監控指標

消費者與消息拉取相關的監控指標如下圖所示：

 

消費組拉取指標的組織分成消費組與該消費組訂閱的多個topic兩個維度。

接下來詳細分析上述指標：

• bytes-consumed-rate

消費端每秒提交到業務的tps。

• bytes-consumed-total

消費端目前消費的總字節數。

• fetch-latency-max

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

• records-per-request-avg

每一次Fetch請求拉取的消息條數(對當前指標取平均值)。

• fetch-rate

客戶端發送Fetch請求的tps。

• fetch-total

客戶端總共發起的Fetch請求個數

• fetch-throttle-time-max

消息拉取(Fetch請求)由于服務端(broker)限流的最大限流時長，關于broker端限流機制，后續會重點探究。

• fetch-throttle-time-avg

消息拉取Fetch請求的平均限流時長。

• fetch-size-max

單個分區一次消息拉取最大的字節數。

實踐指導：該值非常有必要采集監控，可以評估消費端消息的拉取能力，如果該值持續接近設置的期望值，如果消費端tps不滿足需求，可以適當調大該值。

• fetch-latency-avg

消息拉取的平均耗時。

• fetch-size-avg

一次消息拉取的平均字節數

• records-consumed-total

消費端消費端總字節數

• records-lead-min

當前消費位點與日志端中最小位點的差值。

• records-lag-max

分配給消費者的分區中，消息積壓的最大值。

實戰指導：可以基于該值做告警。

消費者還會從主題-分區級別采集與消費進度相關的指標，相關指標說明如下：

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

對于上述指標，主要是解釋一下兩個基本的含義，其他指標是對其進行聚合計算(max,avg)。

• records-lag

消費積壓，即消費位點與當前分區最大位點點差距，該值越大，說明消費端處理速度越慢，需要十分關注，通常需要接入告警，及時通知項目方。

• records-lead

消費位點與當前分區最小位點的差距，我對該值的具體用途暫未參悟，有心的讀者看到，歡迎與我共同交流。

1.3 消費者網絡相關監控指標

上面的指標主要是關注消費端協調器、消費端Fetch(消息拉取)兩個重要維度，接下來關注一下從消息者的視角關注一下底層網絡IO等維度相關的指標，相關指標的采集入口位Kafka的org.apache.kafka.common.network.Selector,其具體的指標如下圖所示：

其實這些指標基本與生產者相同，說明如下：

• request-rate

請求發送tps。

• request-size-max

請求發送的最大字節

• request-size-avg

請求的平均大小

• request-total

總共的請求個數

• select-rate

事件選擇器tps。

• select-total

事件選擇器執行事件選擇的總次數

• response-total

響應請求總數

• response-rate

響應TPS

• outgoing-byte-rate

每秒發送字節數

• outgoing-byte-total

總發送字節數

• incoming-byte-rate

每秒接受字節數

• incoming-byte-total

總工接受字節數

• io-ratio

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

• io-time-ns-avg

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

• io-waittime-total

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

• iotime-total

io處理總時間。

• io-wait-ratio

io等待占io總處理時間的比例

• io-wait-time-ns-avg

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

實戰指導：網絡相關的監控指標，可以重點關注一下io線程相關的性能。

1.4 按broker節點采集監控數據

客戶端還會按照broker的維度，重點采集與請求相關的指標，例如請求tps、平均響應時間。

實戰指導：監控指標的含義都已經在上文中提到過，這些指標應該是最值得采集，特別是request-latency-max、request-latency-avg，這對確認broker是否存在瓶頸。

2、監控指標采集

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

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

在這里插入圖片描述

基本的監控采集系統架構設計如下圖所示：

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

本文轉載自微信公眾號「中間件興趣圈」，可以通過以下二維碼關注。轉載本文請聯系中間件興趣圈公眾號。