赞
踩
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" |
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。