文章目录
技术交流
专家服务
Topic分区热点
KM解决分区热点问题
Topic分区不足
Topic资源治理
异常诊断
项目地址: didi/Logi-KafkaManager: 一站式Apache Kafka集群指标监控与运维管控平台
专家服务
直观的展示和分析当前被管理的集群中出现的问题; 以及可视化运维
Topic分区热点
看到这个词,我们可以先想一想 什么是分区热点,什么情况下会出现分区热点情况;
按照我的理解,我将其罗列为以下几点
什么是分区热点
Topic分区上数据分配不均衡
造成的原因: 当生产者指定了分区数 或者key的时候, 有可能造成某个分区的消息生产速率远远大于其他分区
分区Leader在多个集群中分配不均
造成的原因:多个Broker宕机,导致宕机的Broker上的分区Leader转移到其他Broker上,恢复之后也没有触发 Leader Rebalance, 就会导致,某些Topic的分区Leader分配不均匀;
还有就是新增了很多Broker,某些原因造成新的Broker没有分配到Leader, 又或者把其他分区迁移到了别的 分区等等都会造成这样的问题;
上面的第一种,属于业务逻辑上的热点,我们没法控制,
但是第二种情况可以算作是集群异常点了, 需要我们重新去重新做一下 Leader Rebalance
那么意思是不是只要做一下 Leader Rebalance就解决了？像其他问题导致优先副本本身就不均衡,你再LR也没有用
所以更好的解决办法就是做一下数据迁移;
KM解决分区热点问题
KM判断分区热点逻辑
平台配置
KEY:REGION_HOT_TOPIC_CONFIG
VALUE:
minTopicBytesInUnitB: Topic最近一分钟的每秒评价流量 的阈值 默认3M=310241024
maxDisPartitionNum: Broker直接最大的分区数差值
ignoreClusterIdList: 忽略的物理集群ID
判断逻辑
还有一个判断逻辑是 maxDisPartitionNum: Broker直接最大的分区数差值 ;
像下面的这种分配情况,2-0=2; 如果你的配置 maxDisPartitionNum=1 那么肯定就满足了条件了
KM 解决分区热点–数据迁移
这里的迁移任务跟 Kafka的灵魂伴侣Logi-KafkaManger(4)之运维管控–集群运维(数据迁移和集群在线升级) 是一样的; 这里就不讲解了,不过这里选择的目标BrokerID是默认当前Topic所归属的所有Region下的所有Broker; (相当于把分区在选择的Broker中重新分配了一下)
Topic分区不足
按照一定的规则,来判断是否分区不足, 主要就是计算一下 Topic最近一分钟的平均流量值 / 分区数 是否超过某个阈值(阈值可以自定义);
自定义阈值
首先可以在平台配置那里自定义 判断的条件限定值; (不设置也可以,有默认值)
KEY： TOPIC_INSUFFICIENT_PARTITION_CONFIG
VALUE:
{ "maxBytesInPerPartitionUnitB": 3145728,//每个分区近一分钟的(btyesIn B/s)的最大值 默认是 3M = 3*1024*1024 "minTopicBytesInUnitB": 3145728,//Topic的近一分钟的(btyesIn B/s)值 要大于这个值; 默认是 3M = 3*1024*1024 "ignoreClusterIdList": [ //忽略指定的物理集群; 默认空 0, 1 ] }
判定逻辑伪代码
for(遍历所有Topic){ //（BytesInPerSecOneMinuteRate 表示最近一分钟Topic流入的byteIn(KB/s)值;） if(ignoreClusterIdList){ 忽略 } if(BytesInPerSecOneMinuteRate <= minTopicBytesInUnitB){ 忽略 } if(BytesInPerSecOneMinuteRate / topic的总分区数 < maxBytesInPerPartitionUnitB){ 忽略 } return topic分区热点; }
Topic资源治理
功能不全,待开发
异常诊断
功能不全,待开发
