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

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

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

kennywu76 - wood@Ctrip

赞同来自: 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的处理。 

白衬衣 - 金桥

赞同来自: shjdwxy

80个partition实在太多了,是每秒有大几百万行数据吗?是不是考虑下,用8个partition试试?

kennywu76 - wood@Ctrip

赞同来自:

我们遇到过这个问题,初步调查后大致理解到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,一定程度上缓解了问题。 

laoyang360 - [死磕Elasitcsearch]知识星球地址:http://t.cn/RmwM3N9;微信公众号:铭毅天下; 博客:blog.csdn.net/laoyang360

赞同来自:

我这边遇到rebalance的场景是,kafka集群中有两台机器监听了8083端口,把其中一台停掉,切换到固定一台上能一定层度缓解。

tianqi

赞同来自:

这个问题也有遇到过,我这边发现的是fetch message参数有关,fetch设置过小,一旦kafka堆积就会导致消费不了,所以logstash就会显示一直在reblance了,把这个fetch参数去掉就会缓解很多

taogger

赞同来自:

同样遇到了这个问题,怀疑是心跳跟以及session超时时间设置不合理,不过对应都加长,发现无果,下周继续debug

要回复问题请先登录注册