运维人员如何利用Logi-KafkaManager了解、管控Kafka集群

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

那么今天这篇文章，就让我们来详细了解一下——运维人员是如何去了解和管控我们所有的集群的。

A.运维管控

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

B.接入集群

如何接入集群请看往期内容CSDN好文分享 | Kafka的灵魂伴侣滴滴Logi-KafkaManager

C.物理集群列表

物理集群列表列出了所有物理集群，点击一个物理集群进去可以看到看详细信息。

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

请点击github Logi-KafkaManager/docs/dev_guide/connect_jmx_failed.md查看

Github地址：https://z.didi.cn/4newP

1、集群概览

A.实时流量

指标说明因为我之前发送和消费过消息，所以为了不被之前的数据干扰，我们把Broker重启一下，这样Jmx的数据就会清0了。 历史数据清除就去数据库中把_metrics结尾的表数据全部清空即可。接着可以执行下面的代码，验证一下实时流量的指标准不准确，下面的代码表示的是：60秒发送60条消息、每条消息大小1个字节、但是在这60秒内只发送一次消息，因为linger.ms=60000，所以设置为60秒后发送。那么期望中的实时指标就是：

messagesIn：每秒发送到kafka的消息条数 = 1条；

byteIn：每秒发送到kafka的字节数 = 1字节；

totalProduceReques：每秒总共发送的请求数 = 1/60=0.017 这里是请求数量，因为60s内实际上只发送了一次请求；

执行代码后看看结果，基本上是符合我们预期的，看来实时流量数据还是很准确的。

除了上面几个指标之外，我们还应该关注下面这几个异常指标。正常情况下他们都是0，如果出现不为0的情况说明可能有异常，运维同学此时就应该去查查异常日志了。

1、byteRejected(B/s) ：每秒被拒绝的字节数

2、failedFetchRequest ：每秒拉取失败的请求数

3、failedProduceRequest ：每秒发送失败的请求数

消息条数/总请求数messageIn/totalProduceRequest 也可以关注一下，假如他们的结果=1， 说明没有批量发送，一条消息只发送了一个请求。

B.历史流量

指标说明

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

2、Broker信息

上图左侧部分，是对所有Broker峰值使用率的看板，可以通过这个图简单了解一下Broker的峰值情况。有同学要问了：这个使用率是怎么计算的？计算的到底准不准确？这得去源码里面看看，这个图我们仅作为一个参考值来了解。<