如何在僵屍 state 中檢測 Kafka Streams 應用程序

Question

我們的一個 Kafka Streams 應用程序的 StreamThread 消費者在生成以下日志消息后進入了僵屍 state：

[Consumer clientId=notification-processor-db9aa8a3-6c3b-453b-b8c8-106bf2fa257d-StreamThread-1-consumer, groupId=notification-processor] 成員notification-processor-db9aa8a3-6c3b-453b-b8c8-106bf2fa257d-StreamThread-1-consumer -b2b9eac3-c374-43e2-bbc3-d9ee514a3c16 發送 LeaveGroup 請求到協調器 ****:9092 (id: 2147483646 rack: null) 由於消費者輪詢超時已過期。 這意味着后續調用 poll() 之間的時間比配置的 max.poll.interval.ms 長，這通常意味着輪詢循環花費了太多時間來處理消息。 您可以通過增加 max.poll.interval.ms 或通過使用 max.poll.records 減少 poll() 返回的批次的最大大小來解決這個問題。

StreamThread 的 Kafka Consumer 似乎已經離開了消費者組，但 Kafka Streams 應用程序仍處於 RUNNING state 中，而沒有消耗任何新記錄。

我想檢測到 Kafka Streams 應用程序已經進入了這樣的僵屍 state 以便可以將其關閉並替換為新實例。 通常我們通過 Kubernetes 運行狀況檢查來驗證 Kafka Streams 應用程序是否處於 RUNNING 或 REPARTITIONING state 中，但這不適用於這種情況。

因此我有兩個問題：

1. 當 Kafka Streams 應用程序沒有活躍的消費者時，它是否會保持在 RUNNING state 中？ 如果是：為什么？
2. 我們如何檢測（以編程方式/通過指標）Kafka Streams 應用程序已進入沒有活躍消費者的僵屍 state？

Answer 1

當 Kafka Streams 應用程序沒有活躍的消費者時，它是否會保持在 RUNNING state 中？ 如果是：為什么？

這取決於版本。 在舊版本（2.1.x 和更早版本）中，即使所有線程都死了，Kafka Streams 確實會停留在 RUNNING state 中。 此問題已通過https://issues.apache.org/jira/browse/KAFKA-7657在v2.2.0中修復。

我們如何檢測（以編程方式/通過指標）Kafka Streams 應用程序已進入沒有活躍消費者的僵屍 state？

即使在舊版本中，您也可以在KafkaStreams客戶端上注冊未捕獲的異常處理程序。 每次StreamThreads死亡時都會調用此處理程序。

順便說一句：在即將發布的 2.6.0 版本中，添加了一個新的指標alive-stream-threads來跟蹤正在運行的線程數： https://issues.apache.org/jira/browse/KAFKA-9753

Answer 2

僅供參考，現在用戶郵件列表上正在進行類似的討論——主題行“kafka stream 僵屍狀態”

我將首先告訴你們我在那里說的話，因為到目前為止的對話中似乎存在一些誤解：基本上，錯誤消息有點誤導，因為它暗示這是由消費者自己記錄的，而且它目前是發送這個 LeaveGroup/已經注意到它錯過了輪詢間隔。 但是，當心跳線程注意到主消費者線程沒有在最大輪詢超時內輪詢時，這條消息實際上被記錄下來，並且在技術上只是將其標記為“需要重新加入”，以便消費者知道發送這個 LeaveGroup當它終於再次輪詢時。 但是，如果消費者線程實際上卡在用戶/應用程序代碼中的某個位置並且無法中斷以繼續輪詢循環，那么消費者將永遠不會真正觸發重新平衡、嘗試重新加入、發送 LeaveGroup 請求等。這就是為什么state 繼續運行而不是重新平衡。

由於上述原因，像num-alive-stream-threads這樣的指標也無濟於事，因為線程並沒有死去——它只是卡住了。 事實上，即使線程被卡住了，它也會像往常一樣重新加入然后繼續，它不會“死”（因為只有在遇到致命異常時才會發生這種情況）。

長話短說：代理和心跳線程已經注意到消費者不再在組中，但是 StreamThread 很可能卡在拓撲中的某個位置，因此消費者本身實際上並不知道它已被踢出消費者組