运维最佳实践

Lag 监控

推荐使用我主导开源的项目KCenter

如果希望自研代码监控 Lag 的话,推荐查看我写的文章:如何监控 kafka 消费 Lag 情况

Rebalance Topic

Relalance Topic 推荐采用官方脚本工具kafka-reassign-partitionskafka-preferred-replica-election

工作原理是更改 zk 上的配置,然后触发选举生效。

一、根据 Topic 生成要迁移的 partition 方案

./bin/kafka-reassign-partitions.sh --topics-to-move-json-file topics-to-move.json --broker-list "1,2,3,4,5,6,7" --generate --zookeeper localhost:2181

其中 567 为新加入的 broker

topics-to-move.json

{"topics":
[{"topic": "foo1"},{"topic": "foo2"}],
"version":1
}

二、执行 partition 方案

$ ./bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file partitions-to-move.json --execute

partitions-to-move.json

{"partitions":
[{"topic": "foo",
"partition": 1,
"replicas": [1,2,4] }],
"version":1
}

在执行的过程中记得保留原始分配方案

验证执行结果:

$ ./bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file partitions-to-move.json --verify

Tips💗: 对于整个集群的操作,推荐加入限流参数--throttle,避免流量过高影响整个集群性能。单位为 bytes/sec,最小为 1000(1 KB/s)。

例如: 限制流量为 100MB/s

$ ./bin/kafka-reassign-partitions.sh --throttle 100000000 --zookeeper localhost:2181 --reassignment-json-file partitions-to-move.json --execute

三、优先副本重新选举

bin/kafka-preferred-replica-election.sh --zookeeper localhost:12913/kafka --path-to-json-file topicPartitionList.json

topicPartitionList.json

{
"partitions":
[
{"topic": "topic1", "partition": 0},
{"topic": "topic1", "partition": 1},
{"topic": "topic1", "partition": 2},
{"topic": "topic2", "partition": 0},
{"topic": "topic2", "partition": 1}
]
}

重新选举 Kafka controller

在 zookeeper 上删除/controller

下线 Kafka Leader

该操作可以参考 relalance 方式,唯一不同的是,不更改 topic 上 partition 分配方案,只是调整一下顺序。严格意义上不是下线,只是调整了 leader。

一、执行 partition 方案

例如我们需要将 topic:foo partiton 1 的原 leader 2 下线

原方案:

{"partitions":
[{"topic": "foo",
"partition": 1,
"replicas": [2,1,4] }],
"version":1
}

只需要调整 replicas 数组的顺序就好。

$ ./bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file partitions-to-move.json --execute

partitions-to-move.json

{"partitions":
[{"topic": "foo",
"partition": 1,
"replicas": [1,4,2] }],
"version":1
}

验证执行结果:

$ ./bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file partitions-to-move.json --verify

Tips💗: 对于整个集群的操作,推荐加入限流参数--throttle,避免流量过高影响整个集群性能。单位为 bytes/sec,最小为 1000(1 KB/s)。

例如: 限制流量为 100MB/s

$ ./bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --throttle 100000000 --reassignment-json-file partitions-to-move.json --execute

二、优先副本重新选举

bin/kafka-preferred-replica-election.sh --zookeeper localhost:12913/kafka --path-to-json-file topicPartitionList.json

topicPartitionList.json

{
"partitions":
[
{"topic": "foo", "partition": 1},
]
}

机器更换

  • 使用脚本(bin/kafka-server-stop.sh)停止 broker
  • 拷贝该机器数据目录到新机器上
  • 新机器使用原机器的 broker id,然后重新启动服务即可。

大流量应对之道

限流

数据删除

Topic级别删除相关的参数:

  • cleanup.policy = delete: 只有retention.ms生效
  • cleanup.policy = compact: 只有delete.retention.ms生效
  • cleanup.policy = delete,compact: 两者都生效

log.cleanup.policycleanup.policy 默认值为delete

Topic过期数据真正删除是在新生成segment之后:

  1. segment.ms (默认7天)
  2. segment.bytes (默认1G)

扩容

关键指标监控

  • BytesIn/BytesOut:即 Broker 端每秒⼊站和出站字节数。你要确保这组值不要接近你的⽹络带宽,否则这通常都表示⽹卡已 被“打满”,很容易出现⽹络丢包的情形。
  • MessagesIn:即 Broker 端每秒⼊站消息条数
  • NetworkProcessorAvgIdlePercent:即⽹络线程池线程平均的空闲⽐例。通常来说,你应该确保这个 JMX 值⻓期⼤于 30%。如果⼩于这个值,就表明你的⽹络线程池⾮常繁忙,你需要通过增加⽹络线程数或将负载转移给其他服务器的⽅ 式,来给该 Broker 减负。
  • RequestHandlerAvgIdlePercent:即 I/O 线程池线程平均的空闲⽐例。同样地,如果该值⻓期⼩于 30%,你需要调整 I/O 线程 池的数量,或者减少 Broker 端的负载。
  • UnderReplicatedPartitions:即未充分备份的分区数。所谓未充分备份,是指并⾮所有的 Follower 副本都和 Leader 副本保持 同步。⼀旦出现了这种情况,通常都表明该分区有可能会出现数据丢失。因此,这是⼀个⾮常重要的 JMX 指标。
  • ISRShrink/ISRExpand:即 ISR 收缩和扩容的频次指标。如果你的环境中出现 ISR 中副本频繁进出的情形,那么这组值⼀定 是很⾼的。这时,你要诊断下副本频繁进出 ISR 的原因,并采取适当的措施。
  • ActiveControllerCount:即当前处于激活状态的控制器的数量。正常情况下,Controller 所在 Broker 上的这个 JMX 指标值应 该是 1,其他 Broker 上的这个值是 0。如果你发现存在多台 Broker 上该值都是 1 的情况,⼀定要赶快处理,处理⽅式主要是查 看⽹络连通性。这种情况通常表明集群出现了脑裂。脑裂问题是⾮常严重的分布式故障,Kafka ⽬前依托 ZooKeeper 来防⽌ 脑裂。但⼀旦出现脑裂,Kafka 是⽆法保证正常⼯作的。

参考

  1. PreferredReplicaLeaderElectionTool
  2. replication