【kafka】Kafka常用JMX监控指标整理

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)的请求在那里等待直到被需要的时候。每个类型的请求都有各自的参数配置，从而决定是否（将消息）添加到炼狱中：

1. fetch：当fetch.wait.max.ms定义的时间已到，还没有足够的数据来填充（congsumer的fetch.min.bytes）请求的时候，获取消息的请求就会被扔到炼狱中。

2. 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的数据时会给出响应，根据配置，“接收到”包含三层意思：

1. 消息已接收到，但并未确认(request.required.acks == 0)
2. leader已经把数据写入磁盘(request.required.acks == 1)
3. 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，还需要时刻关注磁盘延迟。