需求

《Bug：Zabbix對Kafka topic積壓資料監控》一文我們透過監控lag來對Kafka某個分割槽topic的消費情況進行告警。透過告警我們發現，分割槽topic的消費積壓情況告警非常頻繁，這無疑會引起開發、運維的重點關注。經過一系列的監控、摸索、實踐、總結，我們逐步發現分割槽topic的消費積壓和以下幾種情況有關：

消費者組頻繁出現Rebalance，導致整個消費者組下的topic都無法消費;

消費者效能問題，無法在超時時間內完成消費;

topic分割槽數和消費者數量不均衡，一個消費者需要消費多個分割槽topic，消費緩慢;

topic分割槽數量變化;

等等

從以上幾種情況分析，無論哪種都和消費者組Rebalance有相關性，都是在經過Rebalance後再重新消費。因此我們還得從Rebalance的角度再出發。

Rebalance再出發

其中關於消費者效能問題，這大多和客戶端的引數設定不恰當相關，這是運維比較難覺察導致。但是為了更全面的瞭解Kafka，我們運維還是很有必要去輕瞭解下的。先從相關引數說起：

1、max.poll.interval.ms

這個引數定義了兩次poll()之間的最大間隔，「預設值為5分鐘」。如果業務處理訊息時間過長，則會導致兩次poll()的時間間隔大於超時時間，從而觸發Rebalance。因此我們應該適當調整每次poll()的數量，以保證在規定時間內處理完訊息，這就需要關注max.poll.records引數了。

2、max.poll.records

這個引數定義了poll()方法最多可以返回多少條訊息，「預設值為500」。poll()的數量如何定義，需要根據業務處理邏輯來決定，例如資料要經過多個資料來源進行處理，一旦某一資料來源訪問超時，無疑都會降低消費效率。比較友好的解決方案是，開發可以根據不同的情況實時調整相關引數，應用側動態感知並進行自動熱載入，達到快速調整消費的效果。

3、消費者組劃分

除了對Kafka引數的調整，我們還要根據業務處理邏輯對消費者組進行提前規劃，避免為了方便將業務相關的topic同時劃分到同一個大消費者組，這樣一旦某個消費者出現問題，將會導致整個消費者組重新Rebalace。如果Rebalance時間過長，此時所有的topic無法消費，那麼實時業務將會受到很大的影響。因此我們要合理分配topic到不同的消費者組。

監控

經過以上的探索分析，我們的首要任務應該是監控Kafka消費者組是否處於Rebalance狀態，進而確定：

分割槽消費者是否發生切換，此時消費者數量不變;

分割槽消費者數量是否減少，出現一個消費者同時消費多個分割槽topic;

分割槽數量和消費者是否為1:1關係，避免出現消費者和分割槽數量不一致的情況;

1.監控思路

在多消費者組的情況下，我們不僅要監控每個消費者組的Rebalance的狀態，還要考慮到未來消費者組的擴充套件，因此我們希望可以透過配置檔案的形式對消費者進行自動發現並新增監控。在此我們仍然是透過Zabbix自動發現，實現對每個消費者組的Rebalance狀態進行監控告警。

2.消費者組自動發現

由於此配置檔案和Kafk topic監控複用同一個檔案，透過Zabbix可對特定消費者組(Group)進行去重識別並行自動發現。