【kafka】Kafka常用JMX监控指标整理
文章目录
- 1.概述
- 一、系统相关指标
- 二、GC相关指标
- 三、JVM相关指标
- 四、Topic相关指标
- 五、Broker相关指标
- 6.kafka生产者指标
- 7.Kafka消费者指标
- 7.1 0.8.2.2版本
- 7.2 0.9.0.0+版本
- 8.zookeeper监控
- 8.1 为什么要用zookeeper？
- 8.2 Zookeeper度量指标
1.概述
参考：
https://cloud.tencent.com/developer/article/1554002
https://www.jianshu.com/p/5b8f43f2a891
一、系统相关指标
1.系统信息收集
java.lang:type=OperatingSystem{"freePhysicalMemorySize":"806023168","maxFileDescriptorCount":"4096","openFileDescriptorCount":"283","processCpuLoad":"0.0017562901839817224","systemCpuLoad":"0.014336627412954635","systemLoadAverage":"0.37"}
2.Thread信息收集
java.lang:type=Threading{"peakThreadCount":"88","threadCount":"74"}
3.获取mmaped和direct空间
通过BufferPoolMXBean获取used、capacity、count
二、GC相关指标
1.Young GC
java.lang:type=GarbageCollector,name=G1 Young Generation{"collectionCount":"534","collectionTime":"8258"}
2.Old GC
java.lang:type=GarbageCollector,name=G1 Old Generation{"collectionCount":"0","collectionTime":"0"}
三、JVM相关指标
通过MemoryMXBean获取JVM相关信息HeapMemoryUsage和NonHeapMemoryUsage；通过MemoryPoolMXBean获取其他JVM内存空间指标，例如：Metaspace、Codespace等
四、Topic相关指标
1.Topic消息入站速率（Byte）
kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec,topic=" + topic{"count":"0","fifteenMinuteRate":"0.0","fiveMinuteRate":"0.0","meanRate":"0.0","oneMinuteRate":"0.0"}
2.Topic消息出站速率（Byte）
kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec,topic=" + topic{"count":"0","fifteenMinuteRate":"0.0","fiveMinuteRate":"0.0","meanRate":"0.0","oneMinuteRate":"0.0"}
3.Topic请求被拒速率
kafka.server:type=BrokerTopicMetrics,name=BytesRejectedPerSec,topic=" + topic{"count":"0","fifteenMinuteRate":"0.0","fiveMinuteRate":"0.0","meanRate":"0.0","oneMinuteRate":"0.0"}
4.Topic失败拉去请求速率
kafka.server:type=BrokerTopicMetrics,name=FailedFetchRequestsPerSec,topic=" + topic;{"count":"0","fifteenMinuteRate":"0.0","fiveMinuteRate":"0.0","meanRate":"0.0","oneMinuteRate":"0.0"}
5.Topic发送请求失败速率
kafka.server:type=BrokerTopicMetrics,name=FailedProduceRequestsPerSec,topic=" + topic{"count":"0","fifteenMinuteRate":"0.0","fiveMinuteRate":"0.0","meanRate":"0.0","oneMinuteRate":"0.0"}
6.Topic消息入站速率（message）
kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec,topic=" + topic
{"count":"0","fifteenMinuteRate":"0.0","fiveMinuteRate":"0.0","meanRate":"0.0","oneMinuteRate":"0.0"}
五、Broker相关指标
1.Log flush rate and time
kafka.log:type=LogFlushStats,name=LogFlushRateAndTimeMs{"50thPercentile":"1.074103","75thPercentile":"1.669793","95thPercentile":"6.846556","98thPercentile":"6.846556","999thPercentile":"6.846556","99thPercentile":"6.846556","count":"19","max":"6.846556","mean":"1.628646052631579","min":"0.512879","stdDev":"1.6007003364105892"}
2.同步失效的副本数
kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions{"value":"0"}
UnderReplicatedPartitions: 在一个运行健康的集群中，处于同步状态的副本数（ISR）应该与总副本数（简称AR:Assigned Repllicas）完全相等，如果分区的副本远远落后于leader，那这个follower将被ISR池删除，随之而来的是IsrShrinksPerSec(可理解为isr的缩水情况，后面会讲)的增加。由于kafka的高可用性必须通过副本来满足，所有有必要重点关注这个指标，让它长期处于大于0的状态。
3.消息入站速率（消息数）
kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec{"count":"86845","fifteenMinuteRate":"0.6456600497006455","fiveMinuteRate":"0.6444164288097876","meanRate":"0.5314899330400695","oneMinuteRate":"0.6494649408329609"}
4.消息入站速率（Byte）
kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec{"count":"57302357","fifteenMinuteRate":"379.11342092748146","fiveMinuteRate":"371.8482236385939","meanRate":"351.37122686037435","oneMinuteRate":"351.8348952308101"}
5.消息出站速率（Byte）
kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec{"count":"246","fifteenMinuteRate":"4.508738367219028E-34","fiveMinuteRate":"1.4721921790135324E-98","meanRate":"0.0015031168286836175","oneMinuteRate":"2.964393875E-314"}
BytesInPerSec/BytesOutPerSec: 通常，磁盘的吞吐量往往是决定kafka性能的瓶颈，但也不是说网络就不会成为瓶颈。根据你实际的使用场景，硬件和配置，网络将很快会成为消息传输过程中最慢的一个环节，尤其是当你的消息跨数据中心传输的时候。跟踪节点之间的网络吞吐量，可以帮助你找到潜在的瓶颈在哪里，而且可以帮助决策是否需要把端到端的消息做压缩处理。
6.请求被拒速率
kafka.server:type=BrokerTopicMetrics,name=BytesRejectedPerSec{"count":"0","fifteenMinuteRate":"0.0","fiveMinuteRate":"0.0","meanRate":"0.0","oneMinuteRate":"0.0"}
7.失败拉去请求速率
kafka.server:type=BrokerTopicMetrics,name=FailedFetchRequestsPerSec{"count":"0","fifteenMinuteRate":"0.0","fiveMinuteRate":"0.0","meanRate":"0.0","oneMinuteRate":"0.0"}
8.发送请求失败速率
kafka.server:type=BrokerTopicMetrics,name=FailedProduceRequestsPerSec{"count":"0","fifteenMinuteRate":"0.0","fiveMinuteRate":"0.0","meanRate":"0.0","oneMinuteRate":"0.0"}
9.Leader副本数
kafka.server:type=ReplicaManager,name=LeaderCount{"value":"92"}
10.Partition数量
kafka.server:type=ReplicaManager,name=PartitionCount{"value":"135"}
11.下线Partition数量
kafka.controller:type=KafkaController,name=OfflinePartitionsCount{"value":"0"}
OfflinePartitionsCount (只有controller有): 这个指标报告了没有活跃leader的partition数，由于所有的读写操作都只在partition leader上进行，因此非0的这个值需要被告警出来，从而防止服务中断。任何没有活跃leader的partition都会彻底不可用，且该parition上的消费者和生产者都将被阻塞，直到leader变成可用。
12.Broker网络处理线程空闲率
kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent{"count":"164506926671008","fifteenMinuteRate":"0.9999327359820058","fiveMinuteRate":"1.0000290054537715","meanRate":"0.9998854371393514","oneMinuteRate":"1.0007836499581673"}
13.Leader选举比率
kafka.controller:type=ControllerStats,name=LeaderElectionRateAndTimeMs{"count":"7","fifteenMinuteRate":"5.134993718576819E-82","fiveMinuteRate":"6.882658450509451E-240","meanRate":"4.2525243043608314E-5","oneMinuteRate":"2.964393875E-314"}
LeaderElectionRateAndTimeMs: 当parition leader挂了以后，新leader的选举就被触发。当partition leader与zookeeper失去连接以后，它就被人为是“死了”，不像zookeeper zab，kafka没有专门对leader选举采用majority-consensus算法。是kafka的broker集群所有的机器列表，是由每一个parition的ISR所包含的机器这个子集，加起来的并集组成的，怎么说，假设一共有3个parition，第一个parition的ISR包含broker1、2、3，第二个parition包含broker2、3、4，第三个parition包含broker3、4、5，那么这三个parition的ISR所在broker节点加起来的并集就是整个kafka集群的所有broker全集1、2、3、4、5。当副本可以被leader捕获到的时候，我们就人为它处于同步状态（in-sync），这意味着任何在ISR池中的节点，都有可能被选举为leader。
LeaderElectionRateAndTimeMs 报告了两点：leader选举的频率（每秒钟多少次）和集群中无leader状态的时长（以毫秒为单位），尽管不像UncleanLeaderElectionsPerSec这个指标那么严重，但你也需要时长关注它，就像上文提到的，leader选举是在与当前leader通信失败时才会触发的，所以这种情况可以理解为存在一个挂掉的broker。
14.Unclean Leader选举比率
kafka.controller:type=ControllerStats,name=UncleanLeaderElectionsPerSec{"count":"0","fifteenMinuteRate":"0.0","fiveMinuteRate":"0.0","meanRate":"0.0","oneMinuteRate":"0.0"}
UncleanLeaderElectionsPerSec: 这个指标如果存在的话很糟糕，这说明kafka集群在寻找partition leader节点上出现了故障，通常，如果某个作为partition leader的broker挂了以后，一个新的leader会被从ISR集合中选举出来，不干净的leader选举（Unclean leader elections ）是一种特殊的情况，这种情况是副本池中没有存活的副本。基于每个topic必须拥有一个leader，而如果首领是从处于不同步状态的副本中选举出来的话，意味着那些与之前的leader没有被同步的消息，将会永久性丢失。事实上，不干净的leader选举将牺牲持久性（consistency）来保证可用性（availability）。所以，我们必须明确地得到这个指标的告警，从而告知数据的丢失。
15.Controller存活数量
kafka.controller:type=KafkaController,name=ActiveControllerCount{"value":"1"}
ActiveControllerCount: kafka集群中第一个启动的节点自动成为了controller，有且只能有一个这样的节点。controller的职责是维护partitio leader的列表，和协调leader的变更（当遇到某个partiton leader不可用时）。如果有必要更换controller，一个新的controller将会被zookeeper从broker池中随机的选取出来，通常来说，这个值（ActiveControllerCount）不可能大于1，但是当遇到这个值等于0且持续了一小段时间（<1秒）的时候，必须发出明确的告警。
16.请求速率
kafka.network:type=RequestMetrics,name=RequestsPerSec,request=Produce{"count":"83233","fifteenMinuteRate":"0.6303485369828705","fiveMinuteRate":"0.6357199085092445","meanRate":"0.5046486472186744","oneMinuteRate":"0.6563203475530601"}
17.Consumer拉取速率
kafka.network:type=RequestMetrics,name=RequestsPerSec,request=FetchConsumer{"count":"125796","fifteenMinuteRate":"1.14193044007404E-33","fiveMinuteRate":"7.699516480260211E-100","meanRate":"0.7623419964866819","oneMinuteRate":"2.964393875E-314"}
18.Follower拉去速率
kafka.network:type=RequestMetrics,name=RequestsPerSec,request=FetchFollower{"count":"375108","fifteenMinuteRate":"2.302746562040189","fiveMinuteRate":"2.292459728166488","meanRate":"2.2721808581484693","oneMinuteRate":"2.2814260196672973"}
19.Request total time
kafka.network:type=RequestMetrics,name=TotalTimeMs,request=Produce{"50thPercentile":"1.0","75thPercentile":"1.0","95thPercentile":"2.0","98thPercentile":"2.0","999thPercentile":"28.0","99thPercentile":"4.0","count":"83384","max":"48.0","mean":"1.2344934279957787","min":"0.0","stdDev":"1.1783192073287214"}
20.Consumer fetch total time
kafka.network:type=RequestMetrics,name=TotalTimeMs,request=FetchConsumer{"50thPercentile":"500.0","75thPercentile":"501.0","95thPercentile":"501.0","98thPercentile":"501.0","999thPercentile":"501.971","99thPercentile":"501.0","count":"125796","max":"535.0","mean":"499.83123469744663","min":"0.0","stdDev":"17.138716708632025"}
21.Follower fetch total time
kafka.network:type=RequestMetrics,name=TotalTimeMs,request=FetchFollower{"50thPercentile":"500.0","75thPercentile":"500.0","95thPercentile":"501.0","98thPercentile":"501.0","999thPercentile":"507.826","99thPercentile":"501.0","count":"375564","max":"532.0","mean":"437.79763502359117","min":"0.0","stdDev":"148.25999023472986"}
22.Time the follower fetch request waits in the request queue
kafka.network:type=RequestMetrics,name=RequestQueueTimeMs,request=FetchFollower{"50thPercentile":"0.0","75thPercentile":"0.0","95thPercentile":"0.0","98thPercentile":"0.0","999thPercentile":"0.0","99thPercentile":"0.0","count":"376206","max":"28.0","mean":"0.0010260336092459982","min":"0.0","stdDev":"0.1282889653905258"}
23.Time the Consumer fetch request waits in the request queue
kafka.network:type=RequestMetrics,name=RequestQueueTimeMs,request=FetchConsumer{"50thPercentile":"0.0","75thPercentile":"0.0","95thPercentile":"0.0","98thPercentile":"0.0","999thPercentile":"0.0","99thPercentile":"0.0","count":"125796","max":"24.0","mean":"0.0018124582657636174","min":"0.0","stdDev":"0.18122860552537737"}
24.Time the Produce fetch request waits in the request queue
kafka.network:type=RequestMetrics,name=RequestQueueTimeMs,request=Produce{"50thPercentile":"0.0","75thPercentile":"0.0","95thPercentile":"0.0","98thPercentile":"0.0","999thPercentile":"0.0","99thPercentile":"0.0","count":"83704","max":"12.0","mean":"2.6283092803211315E-4","min":"0.0","stdDev":"0.042892540270754634"}25.Broker I/O工作处理线程空闲率
kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent{"value":"1.0015540075894207"}
26.ISR变化速率
kafka.server:type=ReplicaManager,name=IsrShrinksPerSec{"count":"0","fifteenMinuteRate":"0.0","fiveMinuteRate":"0.0","meanRate":"0.0","oneMinuteRate":"0.0"}
IsrShrinksPerSec/IsrExpandsPerSec: 任意一个分区的处于同步状态的副本数（ISR）应该保持稳定，只有一种例外，就是当你扩展broker节点或者删除某个partition的时候。为了保证高可用性，健康的kafka集群必须要保证最小ISR数，以防在某个partiton的leader挂掉时它的follower可以接管。一个副本从ISR池中移走有以下一些原因：follower的offset远远落后于leader（改变replica.lag.max.messages 配置项），或者某个follower已经与leader失去联系了某一段时间（改变replica.socket.timeout.ms 配置项），不管是什么原因，如果IsrShrinksPerSec（ISR缩水） 增加了，但并没有随之而来的IsrExpandsPerSec（ISR扩展）的增加，就将引起重视并人工介入，kafka官方文档提供了大量关于broker的用户可配置参数。
PurgatorySize
PurgatorySize: 请求炼狱（request purgatory）作为一个临时存放的区域，使得生产(produce)和消费(fetch)的请求在那里等待直到被需要的时候。每个类型的请求都有各自的参数配置，从而决定是否（将消息）添加到炼狱中：
fetch：当fetch.wait.max.ms定义的时间已到，还没有足够的数据来填充（congsumer的fetch.min.bytes）请求的时候，获取消息的请求就会被扔到炼狱中。
produce：当
request.required.acks=-1，所有的生产请求都会被暂时放到炼狱中，直到partition leader收到follower的确认消息。
关注炼狱的大小有助于判断导致延迟的原因是什么，比如说，导致fetch时间的增加，很显然可以认为是由于炼狱中fetch的请求增加了。
6.kafka生产者指标
kafka的生产者是专门把消息推送到broker的topic上供别人消费的，如果producer失败了，那consumer也将无法消费到新的消息，下面是生产者的几个有用的重要监控指标，保证数据流的稳定性。
| Name | v0.8.2.x MBean Name | v0.9.0.x MBean Name | Description | Metric Type |
|---|---|---|---|---|
| Response rate | N/A | kafka.producer:type=producer-metrics,client-id=([-.w]+) | Average number of responses received per second | Work: Throughput |
| Request rate | kafka.producer:type=ProducerRequestMetrics, name=ProducerRequestRateAndTimeMs,clientId=([-.w]+) | kafka.producer:type=producer-metrics,client-id=([-.w]+) | Average number of requests sent per second | Work: Throughput |
| Request latency avg | kafka.producer:type=ProducerRequestMetrics, name=ProducerRequestRateAndTimeMs,clientId=([-.w]+) | kafka.producer:type=producer-metrics,client-id=([-.w]+) | Average request latency (in ms) | Work: Throughput |
| Outgoing byte rate | kafka.producer:type=ProducerTopicMetrics, name=BytesPerSec,clientId=([-.w]+) | kafka.producer:type=producer-metrics,client-id=([-.w]+) | Average number of outgoing/incoming bytes per second | Work: Throughput |
| IO wait time ns avg | N/A | kafka.producer:type=producer-metrics,client-id=([-.w]+) | Average length of time the I/O thread spent waiting for a socket (in ns) | Work: Throughput |
对生产者来说，响应速率表示从broker上得到响应的速率，当broker接收到producer的数据时会给出响应，根据配置，“接收到”包含三层意思：
- 消息已接收到，但并未确认
(request.required.acks == 0) - leader已经把数据写入磁盘
(request.required.acks == 1) - leader节点已经从其他follower节点上接收到了数据已写入磁盘的确认消息
(request.required.acks == -1)
这看上去很完美，但是对消费者而言，只有当上述的这些确认步骤都准确无误以后，才能读取到producer生产的数据。
如果你发现响应速率很低，那是因为在这个过程中需要牵扯太多因素，一个很简单的办法就是检查broker上配置的request.required.acks参数，根据你的使用场景来选择合适的值，到底是更看中可用性（availability）还是持久性（consistency），前者强调消费者是否能尽快读取到可用的消息，而后者强调消息是否准确无误地持久化写入某个topic的某个partition的所有副本的磁盘中。
Request rate:请求的速率是指数据从producer发送到broker的速率，很显然，请求的速率变化是否健康，也是由使用的场景所决定的。关注速率走势的上和下，对于保证服务的可用性非常关键，如果不开启速率限制（rate-limiting）（0.9+版本才有），那么当流量高峰来临时，broker就将变得很慢，因为他要忙于处理大量涌入的数据。
Request latency average: 平均请求延迟，这是用来衡量从producer调用KafkaProducer.send()方法到接收到broker响应的时长。“接收到”包含很多层意思，可参考response rate那一块。
有多种途径可以减少延迟，主要的途径是producer的linger.ms 配置项，这个配置项告诉producer，在累积够一个消息批次之前，需要等待多久才能发送。默认地，producer只要接收到上一次发送的确认消息后，就立即发送新的消息，但并非所有场景都适用，为了累积消息而等待一点时间会提高吞吐量。
由于延迟和吞吐量有着必然的联系，就很有必要关注batch.size这个producer配置项，从而达到更完美的吞吐量。并不是只要配置一个合适的值就可以一劳永逸了，要视情况决定如何选择一个更优的批大小。要记住，你所配置的批大小是一个上限值，意思是说，如果数据满了，就立即发送，但如果没满的话，最多只等linger.ms 毫秒，小的批量将会导致更多次数的网络通信，然后降低吞吐量，反之亦然。
Outgoing byte rate: 在kafka的broker中，肯定需要监控producer的网络吞吐量，随着时间的变化观察网络上的数据传输量是很有必要的，从而决定是否有必要调整网络设备。另外，也很有必要知道producer是否以一个恒定的速率发送数据，从而让consumer获取到。监控producer的网络传输情况，除了可以决定是否需要调整网络设备，也可以了解producer的生产效率，以及定位传输延迟的原因。
IO wait time: Producer通常做了这么一些事：等待数据和发送数据。当producer产生了超越他发送能力的数据量，那结果就是只能等待网络资源。当如果producer没有发送速度限制，或者尽可能增加带宽，就很难说这（网络延迟）是个瓶颈了。因为磁盘的读写速率往往是最耗时的一个环节，所以对producer而言，最好检查一下I/O等待的时间。请记住，I/O等待表示当CPU停下来等待I/O的时间，如果你发现了过分的等待时间，这说明producer无法足够快地获取他需要的数据，如果你还在使用传统的机械磁盘作为存储，那请考虑采用SSD。
7.Kafka消费者指标
7.1 0.8.2.2版本
在0.8.2.2版本中，消费者指标分成两类：简单消费者指标和高阶消费者指标。
所有简单消费者指标都被高阶消费者采纳，但反过来并非如此。这两者之间最主要的区别就是开发者对于消费者的掌控程度不同。
简单消费者，事实上就是那些被明确地告知连接哪个broker，哪个partition。简单消费者也可以自行管理offset和进行parition leader的选举。尽管为了保证消费者可以真正运行起来，需要做很多工作，但简单消费者也是相对更灵活的。
高阶消费者（也被称为消费者组）忽略了大量实施过程中的细节，那些细节包括offset的位置，broker leader，和zookeeper管理的分区可用性，消费者组只做他最擅长的事，就是消费数据。然而，其实简单消费者更强大，高阶消费者更灵活。
7.2 0.9.0.0+版本
kafka0.9.0.0版本包括了很多新特性，包括了对consumer api的很多大调整。在0.9+以上版本中，专门定义了一类消费者指标，可以通过调用新api得到，这些消费者指标把0.8.2.2中的普通消费者和高阶消费者结合到了一起，而且使用了完全不同的MBean命名空间。
| Name | v0.8.2.x MBean Name | v0.9.0.x MBean Name | Description | Metric Type | v0.8.2.x Consumer Type |
|---|---|---|---|---|---|
| ConsumerLag MaxLag | broker offset - consumer offset kafka.consumer:type= ConsumerFetcherManager, name=MaxLag, clientId=([-.\w]+) | broker offset - consumer offset Attribute: records-lag-max, kafka.consumer:type=consumer-fetch-manager-metrics,client-id=([-.w]+) | Number of messages consumer is behind producer / Maximum number of messages consumer is behind producer | Work: Performance | Simple Consumer |
| BytesPerSec | kafka.consumer:type= ConsumerTopicMetrics, name=BytesPerSec, clientId=([-.\w]+) | kafka.consumer:type=consumer-fetch-manager-metrics,client-id=([-.\w]+) | Bytes consumed per second | Work: Throughput | Simple Consumer |
| MessagesPerSec | kafka.consumer:type= ConsumerTopicMetrics, name=MessagesPerSec, clientId=([-.\w]+) | kafka.consumer:type=consumer-fetch-manager-metrics,client-id=([-.\w]+) | Messages consumed per second | Work: Throughput | Simple Consumer |
| ZooKeeperCommitsPerSec | kafka.consumer:type= ZookeeperConsumerConnector, name=ZooKeeperCommitsPerSec, clientId=([-.\w]+) | N/A | Rate of consumer offset commits to ZooKeeper | Work: Throughput | High-level Consumer |
| MinFetchRate | kafka.consumer:type= ConsumerFetcherManager, name=MinFetchRate, clientId=([-.\w]+) | Attribute: fetch-rate, kafka.consumer:type=consumer-fetch-manager-metrics,client-id=([-.w]+) | Minimum rate a consumer fetches requests to the broker | Work: Throughput |
ConsumerLag/MaxLag:这是所有人都很中意的kafka指标，ConsumerLag是指consumer当前的日志偏移量相对生产者的日志偏移量，MaxLag和ConsumerLag的关系很紧密，相当于是观察到的ConsumerLag的最大值，这两个度量指标的重要性在于，可以决定你的消费者在做什么。如果采用一个消费者组在存储设备上存储大量老的消息，你就需要重点关注消费者的延迟。当然，如果你的消费者处理的是实时消息，如果lag值一直居高不下，那就说明消费者有些过载（overloaded）了，遇到这种情况，就需要采用更多的消费者，和把topic切分成多个parition，从而可以提高吞吐量和降低延迟。
注意：ConsumerLag 是kafka之中过载的表现，正如上面的定义中所描述的额一样，但它也可被用来表示partition leader和follower之间的offset差异。
BytesPerSec:正如前文提到的生产者和broker的关系，也需要监控消费者的网络吞吐量。比如，MessagesPerSec的突然下降可能会导致消费失败，但如果BytesPerSec还保持不变，那如果消费少批次大体量的消息问题还不大。不断观察网络的流量，就像其他度量指标中提到的一样，诊断不正常的网络使用情况是很重要的。
MessagesPerSec: 消息的消费速度并不完全等同于比特的消费速度，因为消息本身可能有不同大小。依赖生产者和工作负载量，在典型的部署环境中，往往希望这个值是相当稳定的。通过随着时间的推移监控这个指标，可以观察出消费数据的趋势，然后定出一个基线，从而确定告警的阈值。这个曲线的走势取决于你的使用场景，但不管怎样，在很多情况下，定出一条基线然后对于异常情况做出告警是很有必要的。
ZooKeeperCommitsPerSec:只有0.8x版本有，如果把zookeeper作为offset的存储（在0.8x版本中是默认的，0.9+版本必须显式地在配置中定义offsets.storage=zookeeper），那你肯定需要监控这个值。注意到如果想要在0.9+版本中明确使用zookeeper作为offset存储，这个指标并没有被开放。当zookeeper处于高写负载的时候，将会遇到成为性能瓶颈，从而导致从kafka管道抓取数据变得缓慢。随着时间推移跟踪这个指标，可以帮助定位到zookeeper的性能问题，如果发现有大量发往zookeeper的commit请求，你需要考虑的是，要不对zookeeper集群进行扩展，要不直接把offset的存储变为kafka（offsets.storage=kafka）。记住，这个指标只对高阶消费者有用，简单消费者自行管理offset。
MinFetchRate: 消费者拉取的速率很好反映了消费者的整体健康状况，如果最小拉取速率接近0的话，就可能说明消费者出现问题了，对一个健康的消费者来说，最小拉取速率通常都是非0的，所以如果发现这个值在下降，往往就是消费者失败的标志。
8.zookeeper监控
8.1 为什么要用zookeeper？
zookeeper在kafka的集群中扮演了非常重要的角色，他的职责是：维护消费者的offset和topic列表，leader选举，以及某些常用的状态信息。在kafka0.8版本中，broker和consumer的协作都是通过zookeeper来进行的，在0.9版本中，zookeeper只是被broker用到（默认是这样的，除非你有其他配置），这样会大大地降低zookeeper的负载，尤其是在大集群中。
8.2 Zookeeper度量指标
可以通过MBean和命令行接口来获取zookeeper的度量指标，
| Name | Description | Metric Type |
|---|---|---|
zk_outstanding_requests
|
Number of requests queued | Resource: Saturation |
zk_avg_latency
|
Amount of time it takes to respond to a client request (in ms) | Work: Throughput |
zk_num_alive_connections
|
Number of clients connected to ZooKeeper | Resource: Availability |
zk_followers
|
Number of active followers | Resource: Availability |
zk_pending_syncs
|
Number of pending syncs from followers | Other |
zk_open_file_descriptor_count
|
Number of file descriptors in use | Resource: Utilization |
Bytes sent/received:在0.8x版本中，broker和consumer都要和zookeeper通信，大规模部署的集群中，有很多consumer和partition，这种和zookeeper连续不断地通信将会成为zookeeper的瓶颈，因为zookeeper是串行处理请求的。根据时间变化跟踪发送和接受数据比特大小可以帮助诊断性能问题。如果zookeeper集群需要连续不断处理大流量，那么就需要为集群提供更多节点，来适应更大数据量。
Usable memory: zookeeper需要加载大量数据到内存中，当需要page到磁盘上的时候是最痛苦的。所以，为了使zookeeper的性能更优，跟踪内存使用率是很有必要的。记住，因为zookeeper是用来保存状态的，所以zookeeper的性能下降将会导致整个kafka集群的性能下降。因此，所有作为zookeeper节点的主机都需要拥有较大的内存，来应对负载的高峰。
Swap usage: 如果发现内存不够了，将会用到swap，如上文提到的那样，这样是不好的，所以你必须知道它。
Disk latency:尽管zookeeper主要是使用内存，但也会用到文件系统，用来有规律地对当前状态做快照，和保存所有事务的日志。由于在update发生以后，zookeeper必须要把事务写到非易失的存储设备上，这是的磁盘的读写存在潜在瓶颈，磁盘延迟的突增，会导致所有与zookeeper通信的服务器响应变慢，所以除了把zookeeper服务器的磁盘换成SSD，还需要时刻关注磁盘延迟。
【kafka】Kafka常用JMX监控指标整理相关推荐
- inodesusedpercent_Linux系统中常用的监控指标整理
今天小编要跟大家分享的文章是关于Linux系统中常用的监控指标整理.正在从事Linux相关工作的小伙伴们来和小编一起看一看吧,希望能够对大家有所帮助! 1. Linux运维基础采集项 做运维,不怕出问 ...
- ML之ME/LF：机器学习之风控业务中常用模型监控指标CSI(特征稳定性指标)的简介、使用方法、案例应用之详细攻略
ML之ME/LF:机器学习之风控业务中常用模型监控指标CSI(特征稳定性指标)的简介.使用方法.案例应用之详细攻略 目录 CSI(特征稳定性指标)的简介 1.如何计算CSI? 2.CSI值的意义 3. ...
- 如何使用JMX监控Kafka
欢迎支持笔者新作:<深入理解Kafka:核心设计与实践原理>和<RabbitMQ实战指南>,同时欢迎关注笔者的微信公众号:朱小厮的博客. 欢迎跳转到本文的原文链接:https: ...
- 4.2.9 Kafka集群与运维, 应用场景, 集群搭建, 集群监控JMX(度量指标, JConsole, 编程获取, Kafka Eagle)
目录 3.1 集群应用场景 1 消息传递 2 网站活动路由 3 监控指标 4 日志汇总 5 流处理 6 活动采集 7 提交日志 总结 3.2 集群搭建 3.2.1 Zookeeper集群搭建 3.2. ...
- 使用JMX监控Kafka
http://blog.csdn.net/eric_sunah/article/details/44980385?utm_source=tuicool 使用JMX监控Kafka 标签: KafkaJM ...
- 基于jmx监控kafka_0542-6.1.0-非安全环境下Kafka管理工具Kafka Eagle安装使用
1.文档编写目的 Fayson在前面的文章介绍了<0374-如何在CDH集群中部署Kafka Manager>,本篇文章Fayson介绍另外一款的监控工具Kafka-eagle,它可以同时 ...
- 关于kafka生产者相关监控指标的理解（未解决）
关于生产者相关的监控指标含义的理解,希望大神帮忙进行确定下. 这边找了官网,看了网上各样的资料,但都无法帮我理解监控项目相关含义. 相关的监控项目是从jconsole获取的,并接入到了zabbix中. ...
- 【kafka】JMX 监控kafka FINER RMI TCP getConnectionId IOException
1.背景 使用Jmx监控kafka相关信息,但是运行的时候报错如下 我的代码大致逻辑是 JMXServiceUrl jmx = new JMXServiceUrl(url) JMXConnector ...
- 【kafka】JMX 监控kafka kafka rmi NoSuchObjectException no such object in table
1.背景 使用Jmx监控kafka相关信息,但是运行的时候报错如下 我的代码大致逻辑是 JMXServiceUrl jmx = new JMXServiceUrl(url) JMXConnector ...
最新文章
- C++之匿名对象与析构函数的关系
- Swagger生成的接口需要权限验证的处理方法
- mysql删除七天_自动备份mysql并删除7天前备份
- 机器学习里面的树形模型
- Java TheadLocal
- insert 数组_Java数组和集合的效率问题
- python的设计哲学是优雅明确简单_Python简单教程
- AD在原理图中高亮网络的两种方法，altium designer 20
- java宠物实训报告,基于Java的宠物用品商城的设计与实现-开题报告
- opencv编译找不到nvcuvid.h文件
- thinkphp-更新数据update函数
- 一个傻瓜式构建可视化 web的 Python 神器 -- streamlit 教程
- Android检测wifi信号强度，检测网络是否通畅
- 数学建模overleaf模板_数学建模论文怎么写？快来pick最优万能模板，一文格式全搞定！...
- unity检测范围内敌人_Unity判断周围是否有敌人
- 网页代码优化html标签,通过优化网页HTML代码提高网页访问速度
- 索尼1000xm3成功配对小米5 蓝牙支持ldac传输
- 登录页面（使用数据库）
- PayPal开发文档整理（8）——PayPal支付产品和解决方案
- 【转载】遥感影响数据集整理