Kafka Cached zkVersion [62] not equal to that in zookeeper, skip updating ISR (kafka.cluster.Partition) 問題分析

我司業務Kafka集群是3節點（broker分別為10,20,30），每個Topic 3 Partition，3 Repilication的配置，早上起床突然發現所有Topic的Broker節點都變為2個了，然后監控發現仍然活着的Broker個數還是3個。那這是怎么回事呢？
通過KafkaManager監控發現，每個Topic的Leader為10的Partition的ISR只有10了，20,30都消失了，而其他Partition的ISR中也都缺少了10。直覺告訴我，10這個節點實際已經被整個集群拋棄了，查看10節點的日志文件，發現日志仍然在增長，並且其他節點的信息也都在正常同步，也就是說10節點還在工作，但是對於整個集群來說，並沒有認可，那么問題是什么呢？由於我們對於Kafka和ZK沒有最基本的監控，所以只能通過有限的監控來判斷問題發生的時間點，然后找到對應的log日志進行排查。
首先需要確認問題發生的時間點，既然kafka級別的監控不全，那么首先從主機級別的流量開始查吧：

比較幸運的是，發現16:19分左右，10節點的流量有個突變，首先是大幅降低，直至為0，然后突然暴漲，后續恢復正常，很明顯是一個10節點離線，然后上線的過程。定位到這個時間點，然后去翻日志，發現20,30節點的日志出奇的類似：

10節點首先被踢出了集群，Shrinking ISR for partition [XXXXXXX,1] from 30,10,20 to 30,20
然后更新ISR的時候報錯：Cached zkVersion [27] not equal to that in zookeeper, skip updating ISR (kafka.cluster.Partition)
這個基本符合我們的猜測，10節點短暫離線，然后上線后，因為20,30update ISR時判斷ZKversion錯誤，中斷更新，導致10節點只是接管了自己是Leader的那些Partition，對於20,30是Leader的那些，很遺憾，認為10一直死着。這真是一個天大的悲劇啊！
那么為什么會產生這個問題呢？通過一陣google，發現這么一篇文章：https://issues.apache.org/jira/browse/KAFKA-2729 。
Kafka-2729Bug，摘抄幾個回復：


ok，我們得出幾個結論，這種問題確實是Kafka與ZK連接短暫中斷引起，並且這個只能通過重啟Kafka節點解決，然后這個在1.1.0版本才得以修復。。。。。。
沒其他辦法，我們只能擇日重啟了10節點的kafka，問題解決。
對於升級這件事情，短期內我們是無法解決的，我們應該如何避免或者第一時間知道此類問題的發生呢？
1. 首先Kafka跟ZK的連接為什么中斷呢？原因很多，比如網絡閃斷，比如ZK繁忙，比如ZKGC時間過長。那么我們需要加大Kafka與ZK連接的超時時間：默認6秒，我們增加到30秒。更新位置：Kafka配置文件，兩個參數更新如下：
zookeeper.session.timeout.ms=30000
zookeeper.connection.timeout.ms=30000
2. 比如對Kafka，ZK建立全面的監控，結合預警，第一時間知曉問題，然后根據監控指標進行分析，而不是撞大運，人工翻日志
如何建立全面的kafka,ZK監控體系呢？別急，下篇揭曉，先上個圖吧：

3. 當然是熟讀源碼，然后知其所以然，然后。。。。由於業務重心不在這一塊，所以這個目標對我而言有點難，各位大牛如果知道此問題的前因后果，歡迎告訴小弟，感激不盡！