logstash 消费kafka数据时，partition持续rebalancing

Logstash | 作者 shjdwxy | 发布于2018年02月07日 | 阅读数：11803

我们使用logstash消费kafka的数据，然后再index到es。kafka的topic有80个partition，因此我们启动了80个logstash实例来消费这个topic。每个logstash kafka input配置了一个thread，所有的logstash实例属于一个group id。
偶尔我们会遇到partition持续rebalancing，一直不能达到一个稳定的状态，非常的头疼。遇到这种情况时只能先减少logstash的数量，然后在增加到80个。
大家有遇到过这个问题吗？

8 个回复

kennywu76 - Wood

赞同来自: medcl 、shjdwxy

我这边一个同事昨天debug了一下，大致找到了问题的源头，下面是他的原话:

关于rebalance, 昨天发现一个有可能的原因. heartbeat 我认为是周期发的, 不会等一批数据处理完了才发heartbeat. 但是一个heartbeat之前有可能已经发了另外一个请求, 比如说offset commit. kafka server本身一定会保证先发的请求先返回, 如果offset commit请求处理很慢, 超过了session的timeout设置, 导致heartbeat请求没有发出去, kafka server就会认为这个member掉出去了. (我自己的实现里面offset commit与heartbeat是用同一个broker connection, 而且两个请求是锁的, 不能同时发. 不清楚java client是不是同一个, 要抓包确认. 不用同一个, 有些浪费. 如果用同一个, 我想也一定要锁, 否则两个请求一起发, tcp内容就乱了)

也就是说在kafka server本身负担比较重的情况下，有可能处理offset commit太慢超时，阻塞了heartbeat的处理。

kennywu76 - Wood

赞同来自: wkdx

我们遇到过这个问题，初步调查后大致理解到kafka broker会检测consumer的心跳，如果一段时间没有心跳回来，会认为有consumer离开，触发rebalancing。但是我们也没有找到问题的根源，因为consumer看起来是在正常的。

最开始我们遇到这个问题的时候情况比较严重，主要是因为logstash kafka plugin默认的conusmer group都是一样的配置，而kafka的rebalance是在consumer group范围内做的，即使这个group内的logstash实例消费的不同的topic。即使是正常的logstash重启，都会导致该group内所有consumer被rebalance。所以后来我们改成每个topic对应一个不同的consumer group，一定程度上缓解了问题。