apache kafka系列之jmx监控指标参数

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/lizhitao/article/details/35986849

Kafka使用Yammer Metrics来监控server和client指标数据。

JMX监控指标参数列表如下:


参数 Mbean名称 说明
所有topic的写入消息速率(消息数/秒) "kafka.server":name="AllTopicsMessagesInPerSec",type="BrokerTopicMetrics" 所有topic消息(进出)流量
所有topic的流入数据速率(字节/秒) "kafka.server":name="AllTopicsBytesInPerSec",type="BrokerTopicMetrics"  
producer或Fetch-consumer或Fetch-follower的请求速率(请求次数/秒) "kafka.network":name="{Produce|Fetch-consumer|Fetch-follower}-RequestsPerSec",type="RequestMetrics"  
所有的topic的流出数据速率(字节/秒) "kafka.server":name="AllTopicsBytesOutPerSec",type="BrokerTopicMetrics"  
刷日志的速率和耗时 "kafka.log":name="LogFlushRateAndTimeMs",type="LogFlushStats"  
正在做复制的partition的数量 (|ISR| < |all replicas|) "kafka.server":name="UnderReplicatedPartitions",type="ReplicaManager" 0
当前的broker是否为controller "kafka.controller":name="ActiveControllerCount",type="KafkaController" 集群中只有一个broker的这个值为1
选举leader的速率 "kafka.controller":name="LeaderElectionRateAndTimeMs",type="ControllerStats" 如果有broker挂了,此值非0
Unclean的leader选举速率 "kafka.controller":name="UncleanLeaderElectionsPerSec",type="ControllerStats" 0
该broker上的partition的数量 "kafka.server":name="PartitionCount",type="ReplicaManager" 应在各个broker中平均分布
Leader的replica的数量 "kafka.server":name="LeaderCount",type="ReplicaManager" 应在各个broker中平均分布
ISR的收缩(shrink)速率 "kafka.server":name="ISRShrinksPerSec",type="ReplicaManager" 如果一个broker挂掉了,一些partition的ISR会收缩。当那个broker重新起来时,一旦它的replica完全跟上,ISR会扩大(expand)。除此之外,正常情况下,此值和下面的扩大速率都是0
ISR的扩大(expansion)速率 "kafka.server":name="ISRExpandsPerSec",type="ReplicaManager" 参见ISR的收缩(shrink)速率
follower落后leader replica的最大的消息数量 "kafka.server":name="([-.\w]+)-MaxLag",type="ReplicaFetcherManager" 小于replica.lag.max.messages
每个follower replica落后的消息速率 "kafka.server":name="([-.\w]+)-ConsumerLag",type="FetcherLagMetrics" 小于replica.lag.max.messages
等待producer purgatory的请求数 "kafka.server":name="PurgatorySize",type="ProducerRequestPurgatory" 如果ack=-1,应为非0值
等待fetch purgatory的请求数 "kafka.server":name="PurgatorySize",type="FetchRequestPurgatory" 依赖于consumer的fetch.wait.max.ms的设置
一个请求(producer,Fetch-Consumer,Fetch-Follower)耗费的所有时间 "kafka.network":name="{Produce|Fetch-Consumer|Fetch-Follower}-TotalTimeMs",type="RequestMetrics" 包括了queue, local, remote和response send time
请求(producer,Fetch-Consumer,Fetch-Follower)在请求队列中的等待时间 "kafka.network":name="{Produce|Fetch-Consumer|Fetch-Follower}-QueueTimeMs",type="RequestMetrics"  
请求(producer,Fetch-Consumer,Fetch-Follower)leader处理请求花的时间 "kafka.network":name="{Produce|Fetch-Consumer|Fetch-Follower}-LocalTimeMs",type="RequestMetrics"  
请求(producer,Fetch-Consumer,Fetch-Follower)等待follower花费的时间 "kafka.network":name="{Produce|Fetch-Consumer|Fetch-Follower}-RemoteTimeMs",type="RequestMetrics"  
发送响应花费的时间 "kafka.network":name="{Produce|Fetch-Consumer|Fetch-Follower}-ResponseSendTimeMs",type="RequestMetrics"  
consumer落后producer的消息数量 "kafka.consumer":name="([-.\w]+)-MaxLag",type="ConsumerFetcherManager"

展开阅读全文

没有更多推荐了,返回首页