Kafka分区未同步排查思路

一、          节点故障或磁盘下线

1.      Kafka节点服务异常

通过FusionInsight Manager页面，选择“集群->Kafka”，查看当前Kafka集群当前状态，状态是否是良好；如果状态不是良好，说明Kafka服务异常。

2.      磁盘下线

通过FusionInsight Manager页面查看告警信息，是否有“Kafka数据目录状态异常”的告警，如果有，server.log日志分析告警产生原因，重启数据目录异常节点。

二、          网络异常

检查网络是否正常方法如下：

• 使用ping -s 15000 IP命令查看是否有网络丢包，如果网络延迟大于5ms，说明网络延迟高。

• 使用scp从客户端传输一个大文件到kafka服务侧节点，查看传输速率。

一般，未完全同步的分区总数监控曲线一直在变化或者通过kafka-topics.sh  --zookeeper zk业务IP:24002/kafka --describe --under-replicated-partitions命令查询处理的未完全同步的分区一直在变化，网络原因的可能性比较大。

三、          副本线程下线

1.     查看未完全同步分区所在节点

执行kafka-topics.sh  --zookeeper zk业务IP:24002/kafka --describe --under-replicated-partitions命令查看所有未完全同步的分区，对比Replicas和ISR列表中的节点，判断未同步的分区是否集中在一个或者几个节点上。例如，下图中ISR列表中都是3未同步。

2.     查看节点信息

执行kafka-broker-info.sh  --zookeeper zk业务IP:24002/kafka查看未同步分区所在节点。

3.     Kafka配置页面查看“num.replica.ers”的配置大小。

4.     切omm用户打jstack信息

根据第二步获取的节点IP，连上此节点，su - omm切omm用户，jps |grep Kafka获取Kafka进程的pid，执行“jstack -l kafkapid >>文件名”，然后cat jstack文件|grep ReplicaFetcherThread-查看同步线程。

注意：

一个副本同步线程的格式如：ReplicaFetcherThread-tid-bid，tid代表一个线程编号，如果配置多个（由服务端配置参数num.replica.ers决定），这个线程号会从0开始依次增加；bid表示leader所在节点的broker-id，如果两个broker之间存在主副本关系，比如：leader在broker-5上，follower在broker-6上，那么broker-6至少会有一个线程名为ReplicaFetcherThread-0-5；如果num.replica.ers配置为2，broker-6 可能会存在两个副本同步线程ReplicaFetcherThread-0-5，ReplicaFetcherThread-1-5。

一个节点理论上能够出现的副本同步线程个数为num.replica.ers *（集群broker实例个数 - 1）。但并不是num.replica.ers配置多少就一定会出现这么多个副本同步线程，线程的数量会根据当前broker节点的分区总数来决定，如果节点上面的副本数很少，kafka会判定分区少而没有必要启动这么多副本同步线程，则副本同步线程个数可能少于num.replica.ers *（broker实例个数 - 1）。通常建议num.replica.ers值配置为3即可，太大会影响CPU的使用率）。

5.     查看分区同步线程是否下线。

如果未查询到同步线程，或者num.replica.ers配置为1且同步线程个数小于（broker实例个数 - 1）的值，或者没有查找此节点到未同步的leader节点的线程，则有同步线程下线。具体可根据未完全同步分区开始上升的时间去server.log日志中排查原因，可搜索“Stopped”、“Shutdown”等关键字查找“ReplicaFetcherThread-”开头的线程是否异常下线。

6.     副本线程下线相关BUG

1） java.nio.BufferOverflowException

2） unexpected offset in append to

3） Attempt to append to a full index

4） Trying to roll a new log segment for partition

以上BUG均在6518及之后版本解决。

四、          节点异常退服

节点退服前未将退服节点上的分区迁移至未退服节点，具体查看方式是执行kafka-topics.sh  --zookeeper zk业务IP:24002/kafka --describe --under-replicated-partitions命令查看所有未完全同步的分区，对比Replicas和ISR列表中的节点，判断未同步的分区是否集中在一个或者几个节点上，如果是，执行kafka-broker-info.sh  --zookeeper zk业务IP:24002/kafka查看节点是否在此列表中，如果没有，确认之前是否退服过节点，如果是，可以确定是退服节点导致。解决办法是迁移退服节点上的分区到正常节点。

五、          Kafka节点压力大

iostat -d -x 1查看CPU参数idle和IO参数util，idle值越高，CPU越空闲，util值越高，IO使用率越高。如果idle值小于20%，top -Hp kafkaPid查看CPU使用率高的线程，打jstack日志分析具体的原因；如果util值大于80%，查看磁盘对应的读写速率、await和svctm的大小判断对IO影响大的原因，如果读写速率比较大，排查kafka读写请求和延时，如果awati远大于svctm，IO队列太长，应用响应时间很慢。

Kafka的数据流量监控中在未同步分区出现时有没有陡增，字节输入输出流量是否达到网络阈值。