Kafka的灵魂伴侣Logi-KafkaManger(3)之运维管控--集群列表

推荐一款非常好用的kafka管理平台,kafka的灵魂伴侣 滴滴开源Logi-KafkaManager 一站式Kafka监控与管控平台

技术交流

有想进滴滴LogI开源用户群的加我个人微信: jjdlmn_ 进群(备注：进群) 群里面主要交流 kakfa、es、agent、LogI-kafka-manager、等等相关技术; 群内有专人解答你的问题 对~ 相关技术领域的解答人员都有; 你问的问题都会得到回应

有想进 滴滴LogI开源用户群 的加我个人微信: jjdlmn_ 进群(备注：进群) 群里面主要交流 kakfa、es、agent、以及其他技术 群内有专人解答疑问,你所问的都能得到回应

文章目录

• • 技术交流
• 运维管控
• • 接入集群
  • 物理集群列表
  • • 集群概览
    • • 实时流量
      • 历史流量
    • Broker 信息
    • • Leader Rebalance
      • Broker详情
      • • 基本信息
        • 监控信息
    • Topic信息 (TODO 页面跳转)
    • 磁盘信息 (TODO 页面跳转)
    • partition信息
    • • Topic分析
    • 消费者信息
    • Region信息
    • • Region列表
    • 逻辑集群信息
    • • 逻辑集群列表
    • Controller信息
    • 限流信息
• 专栏文章列表

项目地址: didi/Logi-KafkaManager: 一站式Apache Kafka集群指标监控与运维管控平台

前面的文章简单介绍了如何接入集群,以及Topic的申请和配额申请,这个时候我们还不是很了解Logi-KafkaManager究竟有哪些优点,如何去管理众多的kafka集群;

今天这篇文章,我们就来详细的了解一下;运维人员如何去了解和管控我们所有的集群

运维管控

运维管控这个菜单栏目下面主要是供运维人员来管理所有集群的;

接入集群

Kafka的灵魂伴侣Logi-KafkaManger一之集群的接入及相关概念讲解

物理集群列表

在这里插入图片描述

列出了所有物理集群,点击一个物理集群进去看详细信息;

如果没有信息请检查一下是否正确开启了JMX; ==> JMX-连接失败问题解决

集群概览

.

实时流量

指标说明

在这里插入图片描述

因为我发送和消费过消息, 为了不让之前的数据干扰; 我们重新把Broker重启一下,Jmx的数据就会清0了; 历史数据清楚就去数据库中把_metrics结尾的表数据全部清空;

在这里插入图片描述

执行下面的代码,验证一下实时流量的指标准不准确; 下面的代码表示的是: 60S秒发送60条消息; 每条消息大小1个字节; 但是在这60S内只发送一次消息; 因为将linger.ms=60000, 设置为60秒后发送; 那么期望中的实时指标是;

    @Test
    void contextLoads() {

            Properties props = new Properties();
            props.put("bootstrap.servers", "xxxxxxx");
            props.put("acks", "all");
            props.put("retries", 0);
            props.put("batch.size", 16384000);
            props.put("linger.ms", 60000);
            props.put("buffer.memory", 335544320);
            props.put("client.id", "appId_000001_cn.Test2");
            props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
            props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
            Producer<String, String> producer = new KafkaProducer<>(props);
            for(int i = 0; i < 60; i++){
                //将一个消息设置大一点
                byte[] log = new byte[1024];
                String slog = new String(log);
                producer.send(new ProducerRecord<String, String>("Test2",0, Integer.toString(i),  slog));
            }
        try {
            Thread.sleep(62000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        producer.close();
    }

messagesIn:每秒发送到kafka的消息条数 = 1条 byteIn:每秒发送到kafka的字节数 = 1字节 totalProduceReques:每秒总共发送的请求数 = 1/60=0.017 这里是请求数量,因为60s内实际上只发送了一次请求;

执行代码然后看结果

在这里插入图片描述

基本上是符合我们预期的,实时流量数据还是准确的;

除了上面几个指标,我们应该还要关注下面几个异常指标，正常情况下他们都是0; 如果不为0的情况说明可能就有异常了,运维同学就应该去查查异常日志了; byteRejected(B/s) 每秒被拒绝的字节数 failedFetchRequest 每秒拉取失败的请求数 failedProduceRequest 每秒发送失败的请求数 messageIn/totalProduceRequest 消息条数/总请求数 也可以关注一下; 假如他们的结果=1; 说明没有批量发送,一条消息就发送了一个请求了

历史流量

指标说明

在这里插入图片描述

历史数据都存放在_metrics结尾的表中;

Broker 信息

在这里插入图片描述

上面左边部分是对所有Broker峰值使用率的看板, 可以通过这个图简单了解一下Broker的峰值情况, 那么这个使用率是怎么计算的,计算的到底准不准确,得需要去源码里面看看, 这个图我们可以作为一个参考值来了解;

在这里插入图片描述

副本状态图, 可以理解为在 ISR中的是同步；不在ISR中的是未同步;

我们现在把其中一台Broker 1 关机 模拟Broker宕机等异常情况; 可以看到变成了下面这样子;

在这里插入图片描述

图中可以看到, 1的状态为未使用, 0,2 两台broker的副本状态都变成了未同步 ;

副本状态: 失效副本分区的个数 大于0 则这个副本状态就展示 未同步 ; 失效副本分区的个数UnderReplicatedPartitions 是通过JMX访问kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions获取到的值;如果获取的UnderReplicatedPartitions值大于0，有可能是某个Broker的问题，也有可能引申到整个集群的问题，也许还要引入其他一些信息、指标等配合找出问题之所在。

注意：如果Kafka集群正在做分区迁移（kafka-reassign-partitions.sh）的时候，这个值也会大于0。

更多关于失效副本分区数异常问题排查请看 失效副本的诊断及预警

理解了副本状态的意思,那上图我们就可以理解了; 之所以Broker[0,2] 都显示未同步,是因为 Broker 2中含有[0,2]的副本; Broker2宕机了,失效副本分区的个数就大于0了

删除操作: 当Broker下线的时候,可以执行删除操作, 一般是当你把这个Broker移除集群的时候你就可以去删除掉他, 不过删除之后,如果重新加入到集群还是会被添加回来的; 如果仅仅只是Broker宕机就不要删除了;

.

Leader Rebalance

在这里插入图片描述

想要知道这个功能用来干什么, 那么我们得先了解一个概念 leader 均衡机制;

Leader 均衡机制（auto.leader.rebalance.enable=true）

当一个broker停止或崩溃时，这个broker中所有分区的leader将转移给其他副本。这意味着在默认情况下，当这个broker重新启动之后，它的所有分区都将仅作为follower，不再用于客户端的读写操作。 为了避免这种不平衡，Kafka有一个首选副本的概念。如果一个分区的副本列表是1，5，9，节点1将优先作为其他两个副本5和9的leader，因为它较早存在于副本中。你可以通过运行以下命令让Kafka集群尝试恢复已恢复正常的副本的leader地位：。不会导致负载不均衡和资源浪费，这就是leader的均衡机制 # kafka版本 <= 2.4 > bin/kafka-preferred-replica-election.sh --zookeeper zk_host:port/chroot # kafka新版本 > bin/kafka-preferred-replica-election.sh --bootstrap-server broker_host:port kafka平衡leader

在配置文件conf/ server.properties中配置开启（默认就是开启）auto.leader.rebalance.enable = true 与其相关的配置还有 leader.imbalance.check.interval.seconds partition 检查重新 rebalance 的周期时间 ; 默认300秒; leader.imbalance.per.broker.percentage 标识每个 Broker 失去平衡的比率，如果超过改比率，则执行重新选举 Broker 的 leader；默认比例是10%; 这个比率的算法是 ：broker不平衡率=非优先副本的leader个数/总分区数， 假如一个topic有3个分区[0,1,2],并且3个副本 ,正常情况下,[0,1,2]分别都为一个leader副本; 这个时候 0/3=0%;

上面几个配置都是 && 的关系; 同时满足才能触发再平衡;

调优建议：考虑到leader重选举的代价比较大，可能会带来性能影响，也可能会引发客户端的阻塞，生产环境建议设置为false。或者周期设置长一点,比如一天一次;

那么如果我们关闭了 均衡机制 , 或者周期时间比较长, 也就有可能造成上面说的问题, 那么Kafka-manager就提供了一个手动再平衡的操作;

假如有一台Broker宕机了, 等它重启之后, 并且等它副本同步完成之后(为了副本同步与再平衡错开一下), 运维管理人员 就可以操作一下这个 Leader Rebalance ;手动触发一下再平衡;

举个栗子