日常运维
问题排查
怎么可能少了滴滴开源的
滴滴开源LogiKM一站式Kafka监控与管控平台

这篇文章源自于,一位群友的问题,而后就写下了这篇文章

进群加V :jjdlmn_

Kafka专栏整顿地址请戳这里0.0

先定义一下名词: 迁徙前的Broker： OriginBroker 、迁徙后的正本 TargetBroker

前提

在这之前如果你比拟理解 分区重调配的原理 的话,上面的可能更好了解;
举荐你浏览一下上面几篇文章(如果你点不进去阐明我还没有公布)

[【kafka源码】ReassignPartitionsCommand源码剖析(正本扩缩、数据迁徙、正本重调配、正本跨门路迁徙)]()
[【kafka运维】正本扩缩容、数据迁徙、正本重调配、正本跨门路迁徙]()

Kafka的灵魂伴侣Logi-KafkaManger(4)之运维管控–集群运维(数据迁徙和集群在线降级)

如果你不想费那个精力,那间接看上面我画的这张图,你本人也能剖析进去可能呈现的问题;以及怎么排查

所有异常情况

Kafka专栏整顿地址请戳这里

1. TargetBroker若不在线,迁徙脚本执行会失败

TargetBroker若不在线, 在开始执行工作脚本的时候，校验都不会被通过呢

情景演示

BrokerId	角色	状态	正本
0	一般Broker	失常	test-0
1	一般Broker	宕机	无

当初将分区topic-test-0 从Broker0 迁徙到 Broker1

sh bin/kafka-reassign-partitions.sh --zookeeper xxxxxx:2181/kafka3 --reassignment-json-file config/reassignment-json-file.json  --execute --throttle 1000000

执行异样

Partitions reassignment failed due to The proposed assignment contains non-existent brokerIDs: 1kafka.common.AdminCommandFailedException: The proposed assignment contains non-existent brokerIDs: 1        at kafka.admin.ReassignPartitionsCommand$.parseAndValidate(ReassignPartitionsCommand.scala:348)        at kafka.admin.ReassignPartitionsCommand$.executeAssignment(ReassignPartitionsCommand.scala:209)        at kafka.admin.ReassignPartitionsCommand$.executeAssignment(ReassignPartitionsCommand.scala:205)        at kafka.admin.ReassignPartitionsCommand$.main(ReassignPartitionsCommand.scala:65)        at kafka.admin.ReassignPartitionsCommand.main(ReassignPartitionsCommand.scala)

2. TargetBroker在开始迁徙过程中宕机，导致迁徙工作始终在进行中

Kafka专栏整顿地址请戳这里

个别这种状况是呈现在, 写入了节点/admin/reassign_partitions/之后, 有一台/N台 targetBroker 中途宕机了, 导致这台Broker不能失常的创立新的正本和同步Leader操作,就不可能持续往后面走了

情景演示

模仿这种状况,咱们能够手动写入了节点/admin/reassign_partitions/重调配信息例如：

创立一个节点写入的信息如下, 其中Broker-1 不在线; 模仿在调配过程中宕机了;
```
{"version":1,"partitions":[{"topic":"test","partition":0,"replicas":[1]}]}
```
看到 /broker/topics/{topicName} 中的节点曾经变更为上面的了
接下来应该要像Broker-1发送LeaderAndIsr申请让它创立正本并且同步Leader；然而这个时候Broker-1是不在线的状态；所以就会导致这个工作始终在进行中, 如果你想进行其余的重调配就会提醒如下
```
There is an existing assignment running.
```
解决办法

只有晓得什么状况,那解决问题思路就很清晰了, 只有把挂掉的Broker重启就行了;

3. 被迁徙正本没有找到Leader,导致TargetReplica始终不能同步正本

Kafka专栏整顿地址请戳这里

只有被迁徙的正本的Leader服务挂了,并且还没有选举出新的Leader, 那么就没中央同步了
这种状况跟状况2相似,但也有不同, 不同在于这里可能是其余的Broker挂了导致的

情景演示

BrokerId	角色	状态	正本
0	一般Broker	失常	无
1	一般Broker	宕机	test-0

当初将分区test-0 从Broker1 迁徙到 Broker0

{"version":1,"partitions":[{"topic":"test","partition":0,"replicas":[0],"log_dirs":["any"]}]}

看下面的图, TargetReplica会收到LeaderAndIsr 而后开始创立正本，并且zk中也写入了TargetBroker的AR信息;
而后开始去同步Leader的正本信息,这个时候Leader是谁? 是Broker-1上的test-0;(只有一个正本)，而后筹备去同步的时候,OriginBroker不在线,就同步不了,所以TargetReplica只是创立了正本,然而还没有同步数据;如下

TargetReplica被创立,然而没有数据; 又因为OriginBroker不在线,所以也没有被删除正本(下图kafka-logs-30 是Broker0;kafka-logs-31是Broker1)
因为整个分区重分配任务没有实现，所以 /admin/reassign_partitions/还未删除
{"version":1,"partitions":[{"topic":"test","partition":0,"replicas":[0]}]}
/broker/topics/{topicName} 中的节点会更新为下图, 其中AR RR都还没有被清空
brokers/topics/test/partitions/0/state节点看Leader为-1，并且ISR中也没有退出 TargetBroker

只有是没有同步胜利,那么整个分区流程就会始终进行中;

解决方案

个别呈现这种状况还是少见的,基本上单正本才会呈现这种状况
个别就算OriginBroker挂了,导致一个正本下线了,那么其余的正本会承当起Leader的角色
如果只有一个正本,那么就会造成这种异常情况了,这个时候只须要把OriginBroker重启一下就行了

4. 限流导致重调配始终实现不了

Kafka专栏整顿地址请戳这里

咱们个别在做分区正本重分配任务的时候,个别都会加上一个限流值
--throttle : 迁徙过程Broker之间传输的速率,单位 bytes/sec
留神这个值是Broker之间的限流, 并不仅仅指的是这次迁徙的几个分区正本的限流；而是蕴含其余Topic本身失常的数据同步的流量; 所以如果你这个限流值设置的很小, 速率比失常状况下的同步速率还要小
又或者你的同步速率比创立音讯的速率都要慢, 那么这个工作是永远完不成的！

情景演示

创立重分配任务, 限流值 1

 sh bin/kafka-reassign-partitions.sh --zookeeper xxxx:2181/kafka3 --reassignment-json-file config/reassignment-json-file.json  --execute --throttle 1

基本上这个速率是别想实现了，admin/reassign_partitions节点始终在
zk中的限流配置

解决方案

将限流阈值设置大一点，从新执行一下下面的脚本，限流值加大

     sh bin/kafka-reassign-partitions.sh --zookeeper xxxx:2181/kafka3 --reassignment-json-file config/reassignment-json-file.json  --execute --throttle 100000000

(尽管这里执行之后还是会揭示你有工作在进行中,然而会重写限流信息的)
千万记得工作完结要用 --verify来把限流值移除掉! 不然他会始终存在的;

5. 数据量太大,同步的贼慢

Kafka专栏整顿地址请戳这里

呈现这个状况是很常见的一个事件,它也不属于异样, 性能问题你没方法,然而往往咱们做数据迁徙的时候会疏忽一个问题； 那就是过期数据太多,迁徙这个过期数据自身就没有什么意义;
能够看我之前的文章 Kafka的灵魂伴侣Logi-KafkaManger(4)之运维管控–集群运维(数据迁徙和集群在线降级)

缩小迁徙的无效数据,可能大大增加数据迁徙的效率;

解决方案

缩小迁徙的数据量
如果要迁徙的Topic 有大量数据（Topic 默认保留7天的数据），能够在迁徙之前长期动静地调整retention.ms 来缩小数据量;
当然手动的来做这个操作真的是太让你烦心了, 你能够有更聪慧的抉择

Kafka的灵魂伴侣Logi-KafkaManger(4)之运维管控–集群运维(数据迁徙和集群在线降级)

滴滴开源Logi-KM一站式Kafka监控与管控平台

可视化的进行数据迁徙、分区正本重调配;

设置限流、减小数据迁徙量、迁徙实现主动清理限流信息

排查问题思路

Kafka专栏整顿地址请戳这里

下面我把我能想到的所有可能呈现的问题解决方案都列举了进去; 那么碰到了
重分配任务始终在进行中怎么疾速定位和解决呢？There is an existing assignment running.

1. 先看/admin/reassign_partitions外面的数据

假如一次工作如下; 有两个分区 test-0分辨别在Broker[0,1] test-1分区在Broker[0,2]

{"version":1,"partitions":[{"topic":"test","partition":0,"replicas":[0,1]},{"topic":"test","partition":1,"replicas":[0,2]}]}

恰好图中Broker1宕机了,test-0就不能实现了,test-1则失常实现; 那么这个时候/admin/reassign_partitions节点就是

{"version":1,"partitions":[{"topic":"test","partition":0,"replicas":[0,1]}]}

所以咱们先看节点的数据，可能让咱们指定是哪个分区重分区呈现了问题 ;

从下面数据能够指定, test-0 这个分区没有实现,对应的Broker有 [0,1]

2. 再看brokers/topics/{TopicName}/partitions/{分区号}/state数据

通过步骤1 我晓得 test-0 有问题,我就间接看节点/brokers/topics/test/partitions/0/state失去数据
这里分两种状况看

如下
```
{"controller_epoch":28,"leader":0,"version":1,"leader_epoch":2,"isr":[0]}
```
能够发现 ISR:[0], 只有0 ；失常来说应该是我下面设置的[0,1]; 那问题就定位在 Broker-1中的正本没有退出到ISR中;
接下来的问题就是排查为啥Broker-1 没有退出到ISR了；
如下, leader:-1 的状况
```
{"controller_epoch":28,"leader":-1,"version":1,"leader_epoch":2,"isr":[0]}
```
leader:-1 示意以后没有Leader; 新增的正本没有中央去同步数据，就很迷茫;
所以接下来要排查的就是其该TopicPartition的其余正本所在Broker是不是都宕机了; 如何确定其余Broker?
看AR是否都失常;AR数据在brokers/topics/{topicName}能够看到 ;
当然你能够通过滴滴开源-LogIKM 一站式Kafka监控与管控平台更简略的去排查这个步骤;如下

3. 依据步骤2确定对应的Broker是否异样

如果找到有Broker异样，间接重启就完事了;

4.查问限流大小

如果步骤3还没有解决问题,也没有Broker异样,那么再判断一下流量限度的问题了

首先看看节点/config/brokers/{brokerId} 是否配置了限流信息;
还有节点/config/topics/{topicName}的信息
并且看到Broker节点也没有退出到ISR, 那么妥妥的同步速率问题了
如果查问到的限流值比拟小的话,能够适当的调大一点
```
     sh bin/kafka-reassign-partitions.sh --zookeeper xxxx:2181/kafka3 --reassignment-json-file config/reassignment-json-file.json  --execute --throttle 100000000      
```
5. 从新执行重分配任务(进行之前的工作)
如果下面还是没有解决问题,那么可能是你正本数据量太大,迁徙的数据太多, 或者你TargetBroker网络状况不好等等,网络传输曾经达到下限,这属于性能瓶颈的问题了，或者你该考虑一下是不是重新分配一下；或者找个夜深人静的早晨做重调配的操作;

情景演示

test-0 分区本来只在Broker [0]中, 当初重调配到 [0,1], 用--throttle 1 模仿一下网络传输速率慢，性能瓶颈等

这个节点始终会存在,始终在进行中,`adding_replicas` 也始终显示[1]

同时能够看到 Broker-1 是存活的

然而不在ISR外面的
判断进去可能同步速率更不上, TargetBroker可能网络情况不好,或者自身压力也挺大；换个TargetBroker
间接删除节点/admin/reassign_partitions ,而后从新执行一下重分配任务; 重调配到[0,2]中
```
{"version":1,"partitions":[{"topic":"test","partition":0,"replicas":[0,2]}]}
```
能够看到曾经在zk中写入了新的分配情况;
然而topic节点中却没有变更AR 和ARS

这是因为Controller尽管收到了节点的新增告诉/admin/reassign_partitions; 然而在校验的时候,它内存外面保留过之前的重分配任务,所以对Controller而言,它认为之前的工作还是没有失常完结的,所以也就不会走后门的流程;
从新选举Controller角色,从新加载/admin/reassign_partitions ; 我在文章[【kafka源码】Controller启动过程以及选举流程源码剖析]()外面剖析过,Controller从新选举会从新加载/admin/reassign_partitions节点并持续工作的执行; 切换之后如下,变更失常

 切换Controller,须要你被动去删除zk节点 /controller
当然还有更简略的形式滴滴开源LogiKM 一站式Kafka监控与管控平台如下

指定一些闲暇的Broker当做Controller,并立刻切换是一个理智的抉择;

解决方案

数据量太大是因为很多过期数据; 如果你重调配的时候没有思考清理过期数据; 那么就重新分配把
然而重分配任务同一时间只能有一个,所以你只能暴力删除/admin/reassign_partitions ;而后重新分配一下;
留神重新分配的时候,请务必设置长期的数据过期工夫,缩小迁徙数据；并且还要让Controller切换一下;
总结起来是
①. 删除节点/admin/reassign_partitions
②. 从新执行重分配任务
③. 让Controller产生重选举

排查工具+思考

Kafka专栏整顿地址请戳这里

剖析完下面的问题, 起始这个问题排查起来,还是挺麻烦的,看这个看那个指标什么的;
是不是能够有一个工具来主动帮我排查问题+提供解决方案;
既然排查思路有了,可视化，自动化，工具化也不是什么难事吧;
所以我在滴滴开源LogiKM 一站式Kafka监控与管控平台上筹备提一个ISSUE, 来简略的实现这么一个性能;
看什么时候比拟空的时候来实现它,你要是有趣味,也能够一起来实现它!

事实案例剖析

周五快下班的时候, 群外面有个同学问了一句上面这个问题, 而后我就我回复了一下;
起初为了具体分析就拉了一个小群来寻找蛛丝马迹

进群加V: jjdlmn_

具体的日志我就不贴出来了,太多了;

这位同学在进行分区重调配的过程中, 长久了很久,始终在进行中, 起初去百度说让在zk中删除重分配任务节点;
我告知了节点之后,而后立马删除了这个节点,起初发现某一台迁徙的 TargetBroker挂了, 让他们重启之后,重调配的工作仍旧接着进行上来了, 也就是说 TargetBroker 仍然失常的实现了正本的调配;

问题剖析

其实这个问题就是咱们下面剖析过的第二种状况 2. TargetBroker在开始迁徙过程中宕机，导致迁徙工作始终在进行中
具体为什么TargetBroker为什么会宕机这不是咱们剖析的领域;

因为TargetBroker宕机了,导致工作不能完结; 这个时候只须要重启TargetBroker就能够了;

尽管他们间接暴力删除了节点/admin/reassign_partitions ; 问题也不大;
影响点在下一次开始重调配的工作时候, Controller内存外面还是报错的之前的信息,所以下一次的工作不会被执行;
然而如果你让Controller重新分配之后,那么就会继续执行了,没有什么影响;

尽管他们这次删除了节点, 也外面开始了下一次的调配; 然而因为它重启了 TargetBroker ；让原来的工作顺利的进行了上来; 哪怕没有切换Controller, 也是不会影响下一次的重分配任务的;(因为顺利进行 Controller被告诉的之前的曾经完结了)

如果你有其余可能呈现的异样,或者其余有对于kafka、es、agent等等相干问题,请分割我,我会补充这篇文章

欢送Star和共建由滴滴开源的kafka的治理平台,十分优良十分好用的一款kafka治理平台

滴滴开源LogiKM 一站式Kafka监控与管控平台

Kafka专栏整顿地址请戳这里

前提

所有异常情况

1. TargetBroker若不在线,迁徙脚本执行会失败

情景演示

2. TargetBroker在开始迁徙过程中宕机，导致迁徙工作始终在进行中

情景演示

解决办法

3. 被迁徙正本没有找到Leader,导致TargetReplica始终不能同步正本

情景演示

解决方案

4. 限流导致重调配始终实现不了

情景演示

解决方案

5. 数据量太大,同步的贼慢

解决方案

排查问题思路

1. 先看/admin/reassign_partitions外面的数据

2. 再看brokers/topics/{TopicName}/partitions/{分区号}/state数据

3. 依据步骤2确定对应的Broker是否异样

4.查问限流大小

5. 从新执行重分配任务(进行之前的工作)

情景演示

解决方案

排查工具+思考

事实案例剖析