前面的文章中,我们简单介绍了如何接入集群,以及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的峰值情况。有同学要问了:这个使用率是怎么计算的?计算的到底准不准确?这得去源码里面看看,这个图我们仅作为一个参考值来了解。<