问题描述
第一次出现是在操作完A号broker的重启后，13号broker的网络线程idle走低
一直到14号发起了一次重均衡（触发leader选举）之后13号（对应下图灰色实例）的broker网络线程idle恢复，转而1号broker（对应下图黄色实例）的网络线程idle开始走低
分析过程
各个broker间的流量没有差异，和network idle match的是broker进程cpu usage，接着看cpu上线文切换也match
再看网络连接虽然有差异，但是蓝色的broker比黄色的broker连接还要多却idle却不低，所以可以排除客户端连接不均
再看包的个数，差异是match的，问题broker的出入包的个数偏多，推断是包过多导致的网络设备中断从而触发cpu上线文切换偏高
包个数有差异但流量都一样，大概是因为多出来的均是是一些小数据包，或只是用于发起三次握手的控制信息包，倾向于后者，接着看tcp相关的指标，发现差异的地方
sync报文太多溢出了listen 队列大小（ /proc/sys/net/core/somaxconn 中配置的10000，其实不算小了）
原因开始明朗
问题在于kafak的生产者和消费者均是长连接，不应该有这么多的新连接请求，于是分别对问题broker（黄色），和没有发生listen 包益处的蓝色实例转取sync包对比分析
tcpdump -i bond0 dst port ${brokerPort} and 'tcp[tcpflags] = tcp-syn'
黄色broker
接着对该客户端单独抓包分析其请求
查看请求包，均是连上来请求加入消费组，但是收到broker的报错信息，然后就是频繁的断开重连
定位到原因
客户端频繁连接某个固定的broker，请求加入某个消费者组，但是该broker不是coordinator，于是返回异常，但是看这种情况客户端不具备异常重连其他broker的能力，还是频繁建连、异常后断开，服务侧的协议栈收到包后会放到本地缓存，然后通知应用层读取，由于sync请求包太多，导致网络请求线程idle低。
那为什么请求线程负载没增呢？
因为应用层发现自己不是协调者直接返回异常，请求还未转给请求线程—待验证
开始联系用户
用户发现客户端确实存在大量报错
关闭服务后，idle升高
客户端层的问题跟进
用户使用的开源组件logstash，没有看该组件sdk这块连接kakfa的机制，目前看现象存在的问题是
1、客户端获取的元数据有问题，访问了不是coordinator的消费者，而且一直访问
可能的原因：
1、kafka的元数据出问题
这次的case 不倾向于是服务侧的元数据问题，因为之前定位到出问题是因为log cleaner挂掉导致的，现在都正常，而且业务侧换了groupID，无效果，报错的broker从转移到了另一个上
2、业务侧的问题–待验证
可以从几个纬度对搜集下线索
1、同一消费者组内的消费者线程是否都有异常
2、同一topic下的不同消费者组是否都有异常
3、所有有异常的消费者使用的组件是否和正常的消费者组件是一个，以及是否是同一个版本
3、服务侧其他未知的bug
