监控Kafka集群

本文主要讲解Kafka集群监控指标及如何监控Kafka集群

对一个Kafka生产环境集群我们需要重点关注如下内容

所有broker执行状态，包括运行状态、所属版本、底层日志路径磁盘使用情况、所在机器的物理负载情况、系统日志是否有严重错误等

ZooKeeper运行状态，包括版本、底层文件系统使用情况，特别是快照所在磁盘空间、所在机器物理负载情况等

集群中所有主题分布以及分区状态，包括所有topic的分区情况以及每个分区leader副本的存活情况等

客户端应用运行状态，包括客户端应用负载分析、有无消费者消费滞后、有无生产者超时等

版本匹配性，全面了解集群中所有clients端应用程序API版本与broker端版本的适配性

集群中定时作业的运行状态，全面了解当前集群中那些大的定时作业，如preferred leader选举或当前正在手动执行哪些耗时作业，如分区重分配

Kafka使用基于yammer metrics的监控指标体系来统计broker段和clients端的各种监控指标

Kafka默认提供了很多监控指标，这些指标都使用JMX接口访问。JMX Java管理扩展，是一套为各种应用程序、设备或系统等植入管理功能的架构。JMX本身是跨平台的，具有很高的灵活性，可以无缝集成进各种系统中。Kafka集群大部分的运行表现都可以由JMX指标来表征，对于搭建一套能够访问JMX的监控框架或系统对于监控Kafka集群至关重要

Kafka的每个监控指标都是以JMX MBean的形式定义，MBean代表一个被管理的资源实例，表示管理资源的Java对象，每个bean的管理接口如下

属性值

能够执行的操作

能发出的通知事件

构建器

Kafka中MBean的属性值，包含了Kafka各种监控指标的真实值。MBean需要注册之后才能使用，注册时必须指定MBean的名称。Kafka中，所有MBean的命名规范有着统一的格式xxx.type=xxx,{attr}=xxx。第一个等式中的xxx通常表示所属的Kafka组件,比如kafka.server、kafka.producer或kafka.consumer等；第二个等式中的xxx和前面的attr通常表示该MBean的范围，比如topic=test表示该MBean的作用范围为名为test的topic，表示该topic下的某个指标

对于Java用户，访问JMX接口最简单的方式是使用JDK自带的JConsole工具。无论用户使用那种工具监控Kafka，用户至少需要指定连接JXM的IP和端口。在JDK安装目录bin下运行jconsole,mac 默认JDK安装目录在/Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/。由于Kafka默认是不开启 JMX远程监控的，需要启动Kafka服务时开启，运行JMX_PORT=9997 ./kafka-server-start.sh -daemon …/config/server.properties启动Kafka服务即可开JMX远程监控，但默认是不开启认证的。开启认证可参考官网http://kafka.apache.org/documentation/#monitoring

Kafka JMX MBean命名规范中第一项即指定该MBean所属的Kafka组件，JMX监控指标共有5大类

Kafka broker端指标，具体可分为一下几个指标

kafka.server：服务端JMX指标

kafka.network：网络相关JMX指标

kafka.log：分区日志相关JMX指标

kafka.Controller：controller相关JMX指标

clients端常用指标：包括所有clients端公共的一些指标，clients包括producer、consumer、connect、streams

producer端指标：定义Java版本producer API调用过程中各种JMX统计指标，MBean命名通常以kafka.producer开头

consumer端指标：定义Java版本consumer API调用过程中的各种JMX统计指标，MBean命名通常以kafka.consumer开头

Streams端指标：定义Kafka Stream的JMX指标，MBean命名以kafka.stream开头

用户可以查询官网中各类指标的定义列表，获取对应的MBean名称，在监控框架中实时进行观测

要远程监控broker及clients端应用，需要在启动broker及clients端应用时指定JMX监控端口，可以通过设置JMX_PORT环境变量设置JMX监控端口

对于一个陌生的Kafka集群，可以通过查看Kafka使用的ZooKeeper中的/brokers/ids/节点数据，查看JMX暴露的端口。如果未指定JMX端口， ZooKeeper中保存的jmx_port是-1

Kafka提供了很多broker端的JMX监控指标，这些监控指标几乎都是Kafka开发过程中"踩过坑的"，是Kafka调试及bug修复过程中相当重要的指标。在实际生产环境中，用户一定要对broker端JMX指标做监控

消息入站/出站速率使用的单位是字节/秒，分别表示Kafka broker每秒接收/发送的消息字节数。接收指接收来自producer端发送的消息或follower broker接收来自leader broker发送的消息。发送指leader broker将消息备份到follower broker

这两个MBean支持topic级别的统计，表示当前broker处理各个topic分别计算入站速率和出站速率。如果要单独查询某个topic的消息速率，需要将topic名称加入到MBean名称中。假设查询topic名为test的入站速率，需要指定MBean名称为kafka.server.type=BrokerTopicMetrics,name=BytesInPerSec,topic=test.Kafka为这两组MBean还定义了许多属性

在生产环境下，用户需要实时观测上述表格属性值，如果发现入站速率或出站速率接近broker所在机器的网络带宽，则表明该broker可能是一个瓶颈，考虑是否将该broker的负载转移到其他broker上。实际监控过程中可能出现消息出站速率是消息入站速率好几倍，这中情况确有可能，对于一台broker，如果它是某个分区的leader，该topic的副本因子是3，则意味着该broker接收到producer发送的一条消息后需要将这条消息发送到其他两台broker上，故统计出来的BytesOutRate指标值确有可能是BytesInRate指标值的数倍

一旦controller挂掉了，整个集群的运行都会受到非常严重的影响，在实际生产环境中一定要实时监控controller存活状态。controller的JMX指标中表征controller是否存活的JMX指标是kafka.controller.type=KafkaController,name=ActiveControllerCount，即当前集群active controller的数量，该MBean值应该始终等于1才正常，在目前Kafka的设计中任意时刻只允许有一个运行中的controller。如果该值长时间为0，则表示controller已经被关闭且未能自行进行选举，通常这种情况都是严重的故障，需要马上介入处理，因为controller无法处理任何的broker间请求以及用户发起的管理任务。可以 查看controller所在broker的controller日志（controller.log、state-change.log)来定位问题。若无法马上定位问题，可先恢复controller，恢复方式有如下两种

删除ZooKeeper节点/controller：删除此znode可触发controller重新选举

重启controller所在broker：若上述方法失效，可以考虑这种方式，但这样通常对业务有较大冲击，实际使用需谨慎

该指标给出当前broker上分区leader副本备份不足的程度，备份不足的分区指那些当前ISR中副本数少于副本因子的分区。假设一个topic的副本因子是3，有10个分区，若某一时刻，有5个分区的ISR副本数是2，则该topic上副本不足的分区数就是5。该MBean统计的是整个集群上所有topic的情况。该指标的统计规则有两个条件，除计算备份不足外，还要保证统计的分区的leader副本就位于该broker才行，如果该broker上某个分区的follower副本备份不足，那么这个分区是不会计入此broker对应MBean值的

此MBean的名称为kafka.server.type=ReplicaManager,name=UnderReplicatedPartitions。在实际生产环境中，此值越小越好，0是最好情况，一旦发现此值长时间大于0，用户需要检查该broker作为leader的那些分区当前副本备份情况，是否出现follower副本长时间无法追上leader副本或broker发生崩溃情况

如果该MBean值持续波动但未发现有broker奔溃，可能是性能问题，即有follower副本经常被踢出ISR的情况，此时需要查看出问题follower broker日志来详细定位问题

Kafka的MBean指标kafka.server.type=ReplicaManager,name=LeaderCount统计了该broker是多少个分区的leader副本，单看某个broker上该指标意义不大，需要在整个集群上查看。比较理想的情况是，集群上所有broker的该MBean值都相差无机，表明整个负载被均匀分配到了所有broker上

Kafka在创建分区时会尽量做到负载均衡，但集群长时间运行后，有可能出现某些broker承载过多分区leader角色，如果发现某些broker的MBean值异常高，可以使用bin/kafka-reassign-partitions.sh脚本对现有分区分布进行重调整

ISR变化指ISR扩张和收缩，当有新的follower副本追上leader副本进度时，会被加入ISR中：若存在follower副本无法追上leader副本进度，则会被"踢出"ISR，ISR经常变化通常会带来一些性能问题，可能造成broker上负载流量经常性波动，还可能预示着经常有broker挂掉的情形出现

这组MBean对应的名称分别是kafka.server:type=ReplicaManager,name=IsrExpandsPerSec和kafka. server:type=ReplicaManager，name=IsrShrinksPerSec。在实际场景中这两个值接近0才是正常情况，表明没有经常性ISR变化

若发现该组值长时间大于0，则需要查看集群中各个broker是否经常性宕机

默认每台broker会创建8个工作线程，由参数num.io.threads指定，用来处理外界发往该broker的各种请求，为实时监控该broker的工作负载情况，Kafka提供了kafka.server.type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent来统计线程的空闲率

该MBean值表示的是所有I/O工作线程处于空闲状态的时长与总运行时长的比值，实际使用场景中建议该值不要小于30%，如果某台broker的这个指标降低到很低水平，说明此broker承担的负载过重，需要考虑将一部分负载移到其他broker上

默认每台broker会创建3个网络处理线程，由num.network.threads指定，用于处理网络接收请求和发送响应，为实时监控这些processor线程工作状态，Kafka提供了kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent来统计这些线程总的空闲率

该MBean表示所有网络处理线程处于空闲状态的时长与总运行时长的比值，实际使用场景中建议该值不小于30%，如果某台brokerMBean降到很低，说明此broker无法及时从网络中接收请求或发送响应，可能造成请求堆积，如果CPU资源比较充足，可以考虑增加该参数值，否则需要增加broker请求队列的大小以缓存更多入站请求和出站响应（增加queued.max.requests参数值）

Kafka通过kafka.log:type=Log,name=Size,topic=,partition=指标统计每个topic的总消息字节数。假设一个名为test的topic有10个分区，那么用户可以查询kafka.log:type=Log,name=Size,topic=test,partition=0到kafka.log:type=Log,name=Size,topic=test,partition=9的字节数，相加便能得出test总的字节数

每个producer端的JMX指标都有一个对应的client ID，用于标识该指标统计的是哪个producer的数据。相比broker端单个MBean只定义单个属性不同，Java版本producer的JMX指标非常少，但定义的属性却非常多，这大大方便了用户实时观测producer应用运行情况，不用在多个MBean之间切换。MBean名字由client ID指定，完整格式是kafka.producer:type=producer-metrics,client-id=.除可以整体上监控producer，Kafka还运行用户指定节点序号和topic，分别从Kafka节点和topic维度查看相应运行指标，其MBean格式分别为kafka.producer:type=producer-node-metrics,client-id=,node-id= 和 kafka.producer:type=producer-topic-metrics,client-id=,topic=

其中比较重要的属性及含义如下

完整的参数详情看kafka官网关于监控部分

consumerJMX大致分为如下几类

fetcher-manager：统计consumer底层fetcher的各种状态信息，MBean为kafka.consumer:type=consumer-fetch-manager-metrics,client-id=

consumer：统计consumer状态信息，MBean名称为kafka.consumer:type=consumer-metrics,client-id=

coordinator：统计consumer coordinator状态信息，MBean名称为kafka.consumer:type=consumer-coordinator-metrics,client-id=

fetcher JMX属性包含了一些公共的属性以及topic级别的属性

fetch-latency-avg：该属性与producer端的request-latency-avg含义类似，如果该值比较大，可以尝试调优consumer端参数fetch.max.wait.ms和fetch.min.bytes

bytes-consumed-rate：表示每秒经由此consumer消费的字节数，在实际生产中建议用户对此值做一个基准测试并确定业务稳定时的阈值，如果发现该值严重偏离阈值，需要仔细确认造成偏离的具体原因

coordinator相关属性

assigned-partitions：统计consumer被分配的分区数，利用此属性可以知道consumer group中所有成员的分区数是否被均匀分配

join-time-avg：统计该consumer加入consumer group的平均时间

sync-time-avg：统计该consumer执行组同步操作的平均时间

commit-latency-avg：统计该consumer提交位移的平均延时

consumer相关属性

request-rate：统计consumer平均每秒发送的FETCH请求数

request-size-avg：统计consumer平均每秒发送的FETCH请求字节数

Kafka是标准的JVM系框架，必须运行在JVM上，除监控Kafka提供的JXM监控指标外，用户还必须实时监控Kafka broker运行环境中的JVM，JVM运行状态及性能直接决定broker表现

JVM监控必须关注一下两点

进程状态

GC性能

JVM默认提供了很多JMX指标，有两个比较关键指标需要用户进行日常监控，分别是java.lang:type=OperatingSystem,MaxFileDescriptionCount和java.lang:type=OperatingSystem,OpenFileDescriptorCount，前者定义单个JVM进程运行打开的最大文件描述符个数，后者统计当前该JVM进程使用的文件描述符

如果发现以上两者接近，需要调整前者的最大值，通常需要运行ulimit -n来指定最大的FD值，对于底层有很多分区数据的broker，这个值会增加的很快，因此务必注意此指标

JVM GC性能监控与调优，其中有两个比较重要的JMX指标java.lang:type=GarbageCollector,name=G1 Old Generation 和java.lang:type=GarbageCollector,name=G1 Yong Generation，前者收集G1垃圾收集器老年代统计信息，包括收集次数、收集时长；后者表示G1新生代统计信息，同样包括次数和时长，这里的时长信息的单位是毫秒，统计了自JVM启动开始用于垃圾收集的时间

这两个指标还有一个LastGcInfo属性，保存最近一次GC的详情信息，此属性是一个复合属性，里面比较重要的是duration值，告诉用户上次GC花费时间

用户还需要实时监控Kafka broker所在机器操作系统状态，包括：CPU使用率、内存利用率、磁盘繁忙程度、磁盘使用率、磁盘I/O状态和网络利用率

在Linux平台可以使用top工具查看CPU使用率，在提供的各种指标中首先需要查看的是系统负载情况，其直观给出当前系统运行的负载状态（load average），如果load值长时间大于系统核数，则说明系统负载已经饱和，用户需要将该broker负载分散到其他机器上，常见的性能指标包括如下几种

us：在用户态执行应用程序的时间百分比

sy：运行内核代码的时间百分比

id：CPU处于空闲状态的时间百分比

wa：等待物理I/O的时间百分比

通过上述指标，用户可以大致判断当前broker所在机器CPU负载情况，CPU使用可以使用us + sy或 100 - id计算，如果该值长时间处于高位则需要结合JDK工具jstack定位消耗CPU线程，CPU利用率处于高位不一定是坏事，实际环境中用户可以监控等待队列来定位CPU是否处于瓶颈

等待队列保存的是等待CPU时间片的线程，如果该值长时间大于CPU核数且CPU使用率处于高位，表明系统CPU处于瓶颈，linux可以通过vmstat查看等待队列值

磁盘监控重点在于磁盘读/写使用率上，linux可以通过iostat -d -x -k 1 5来监控%util列的值，如果该值长时间保持95%以上则表明磁盘I/O是系统瓶颈

网络带宽监控，Kafka broker与clients以及broker之间都需要大量的RPC通信，Kafka需要消耗大量带宽，一定要保证broker所在机器的入站/出站带宽不要过于接近允许的最大带宽，否则会出现无法处理请求或请求超时情况，liunx可以通过nload和iftop监控网络带宽

监控Kafka的工具有很多，例如JmxTool、kafka-manager、Kafka Monitor、Kafka Offset Monitor、CruiseControl.如果你的生产环境有使用Prometheus作为监控中间件的工具，那建议你使用Prometheus进行监控