Kafka问题排查

Kafka无法消费问题排查

目录

Kafka无法消费问题排查

1、问题现象

2、问题排查过程

1、Zookeeper处理

2、调整参数重启broker

3、kafka在Zookeeper元数据处理

4、__consumer_offsets处理

3、总结

---

1、问题现象

最近在生产环境遇到消费者无法消费kafka的问题，kafka版本是kafka_2.10-0.10.2.1。业务测反馈部分消费程序无法消费数据，但是写入正常，并且部分消费程序可以消费，共10台消费程序无法消费，消费者组共

2、问题排查过程

1、Zookeeper处理

查看zookeeper日志，发现zookeeper一直在打开关闭连接。结合之前生产环境遇到的zookeeper服务出现过fullgc过长导致异常，对zookeeper进行重启，重启后并未解决问题。查看zookeeper establise的连接发现很高，尝试对zookeeper连接数调大maxClientCnxns由500调整到1500，依然未解决消费问题。分析：maxClientCnxns代表每个客户端和zk的连接数，连接数虽然多，但是单个客户端和zk连接数没有达到阈值，所以应该不是瓶颈。查看zookeeper日志，发现客户端确实已经连接上zk，但是仍然无法消费。

2、调整参数重启broker

通过调整kafka以及zookeeper一些参数,加大kafka以及zookeeper一些超时参数，对kafka以及zookeeper进行重启，重启后依然无法消费。检查topic状态，发现部分topic分区异常没有上线，定位到一台broker没有启动成功。分析启动失败的broker日志，发现有分区异常，删除该异常分区物理文件，重启该broker，kafka所有topic恢复正常，但是消费者仍然无法消费，

3、kafka在Zookeeper元数据处理

查看zookeeper中/consumer目录，发现/consumer下有1400多个node,都是consumer开头的消费者。当前版本的kafka应该只有通过kafka-console-consumer.sh脚本进行消费的会存储在zookeeper中/consumer，都是测试用的，通过java api进行消费并且使用高级API的会自动由kafka管理，记录在名__consumer_offsets的topic。业务消费目前都是由kafka管理的，考虑可能是zookeeper压力大导致，删除zookeeper中/consumer目录，部分消费程序开始恢复正常，3台恢复正常，7台依然无法消费。

4、__consumer_offsets处理

7台无法消费的是同一个消费者组，将业务侧日志提高到trace级别，发现日志中出现了以下日志

Sending Join Group……

Marking the cordinator …… dead for group ……

Attempt to join group …… failed due to obsolete coordinator information:This is not the correct coordinator for this group

分析日志应该是消费者组没有加入成功，分析kakfa消费者组的方式，kafka管理offsets在__consumer_offsets，默认有50个分区，broker承载着group coordinator的角色，显然没有加入成功。_consumer_offsets 也是一个 topic ，那么它就也分了 Partition ，比如他就分为 n 个 Partition，则 Coordinator的选择方法就是 leader(abs(group.hashcode) % n) , 也就是用 consumer group 的名字的 hashcode 对__consumer_offsets 的分区数取模，得到一个分区编号，然后这个分区的 leader 在哪台 Broker 上，哪台 Broker 就是这个Consumer Group 的 GroupCoordinator。找到该消费者组的broker，发现该分区的offsets文件特别大，已经达到了2.1T，但是其他isr副本并没有这么大的文件。猜测可能是文件太大，导致无法加载到内存提供服务。

• 1. 重启该broker，使其他服务器被选举为leader提供服务。重启后，业务反应可以进行消费，但是消费较慢。猜测还是和文件大小有关。
  2. 排查__consumer_offset其他partition是否有较大分区leader，分别进行重启。业务反应不能消费了，发现第一台重启的再次变成了leader。
  3. 对第一台再次重启，作为replica，leader重新选举。业务反应可以消费，观察一会，没有出现卡顿现象。
  4. 为避免__consumer_offsets再次出现大量的小文件，默认的策略是compact。将默认策略的改为删除策略，clean.policy=delete。并减少保存周期，retention.ms=259200000,保留3天。目前观察__consumer_offsets分区最大在数十G左右。

3、总结

1. __consumer_offsets修改策略后，仍然存在数十G的文件，有点不太正常，猜测和每天的数据量有关，每天近千亿数据，提交特别频繁，每次提交都会产生记录，大量的提交记录导致文件很多，暂无想到较好的应对措施。最好不通的topic用不通的消费者组，这样消费者组尽量均衡到不同分区，减少部分分区的压力

2.业务侧反馈恢复正常后，偏移量丢失。分析日志暂时没有发现原因

猜测:

和kafka内部机制有关系，offset保存broker没有复制到其他的replica,重启后同步最新的leader，导致原始offsets丢失.