Kafka中的这只“千里眼”，你需要知道

Consumer-coordinator-metrics

消费者组协调器相关的监控指标。

Consumer-fetch-manager-metrics

消费组消息拉取相关的监控指标

Consumer-node-metrics

以broker节点为维度的统计信息，消费端向多个broker节点拉取消息等监控指标。

Kafka-metrics-count

接下来将分别展开，详细介绍其各个指标的含义，并给出一些实践指导。

1.1 消费者组协

【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】浏览器打开：qq.cn.hn/FTf 免费领取

调器监控指标

组协调器相关的监控指标明细说明如下：

详细说明如下：

join-time-max

消费者重新加入消费组的最大时长

join-time-avg

消费者重新加入消费组的平均时长

join-rate

消费者加入消费组的TPS

实践指导：该值为0正常，该值越大，越有问题，说明消费者在频繁加入消费者，在加入消费者的过程中消费者是不会消费消息的。

join-time-avg

消费者加入消费组的平均时间

join-total

该消费者重新加入消费组的次数（重平衡发生的次数）

实践指导：该值值的采集，如果该值过大，说明发生重平衡的次数太多，重平衡时该消费者时不参与消息消费。

commit-latency-avg

提交位点的平均耗时

commit-rate

提交位点的tps

commit-latency-max

提交位点时的最大延迟时间

commit-total

消费者启动以来位点提交的总次数

sync-time-avg

消费者发送sync的平均响应时长。

知识点：消费者加入小组后由该消费者中的Leader负责进行队列分配，然后将分配方案发送给组协议器，各个从节点将向组协调器获取分配队列。

sync-rate

消费者发送sync的tps

sync-total

消费者发送sync请求的总次数

sync-time-max

消费者sync请求响应的最大响应时间

assigned-partitions

当前分配到的分区数量

heartbeat-total

心跳请求的总数

heartbeat-response-time-max

心跳请求的最大响应时间

last-heartbeat-seconds-ago

上一次发送心跳包的时间

heartbeat-rate

发送心跳包的tps

从监控指标来看，我们有能得知消费端协调器的职责：

协调消费者加入消费组
协调消费者Leader进行队列负载分配
发送心跳，保持会话
提交位点

1.2 消费者消息拉取监控指标

消费者与消息拉取相关的监控指标如下图所示：

消费组拉取指标的组织分成消费组与该消费组订阅的多个topic两个维度。

接下来详细分析上述指标：

bytes-consumed-rate

消费端每秒提交到业务的tps。

bytes-consumed-total

消费端目前消费的总字节数。

fetch-latency-max

API.FETCH请求(即向broker端发送消息拉取)的最大耗时。

records-per-request-avg

每一次Fetch请求拉取的消息条数（对当前指标取平均值）。

fetch-rate

客户端发送Fetch请求的tps。

fetch-total

客户端总共发起的Fetch请求个数

fetch-throttle-time-max

消息拉取(Fetch请求)由于服务端(broker)限流的最大限流时长，关于broker端限流机制，后续会重点探究。

fetch-throttle-time-avg

消息拉取Fetch请求的平均限流时长。

fetch-size-max

单个分区一次消息拉取最大的字节数。

实践指导：该值非常有必要采集监控，可以评估消费端消息的拉取能力，如果该值持续接近设置的期望值，如果消费端tps不满足需求，可以适当调大该值。

fetch-latency-avg

消息拉取的平均耗时。

fetch-size-avg

一次消息拉取的平均字节数

records-consumed-total

消费端消费端总字节数

records-lead-min

当前消费位点与日志端中最小位点的差值。

records-lag-max

分配给消费者中分区中，消息积压的最大值。

实战指导：可以基于该值做告警。

消费者还会从主题-分区级别采集与消费进度相关的指标，相关指标说明如下：

records-lag
records-lag-avg
records-lag-max
records-lead
records-lead-avg
records-lead-min

对于上述指标，主要是解释一下两个基本的含义，其他指标是对其进行聚合计算（max,avg）。

records-lag

消费积压，即消费位点与当前分区最大位点点差距，该值越大，说明消费端处理速度越慢，需要十分关注，通常需要接入告警，及时通知项目方。

records-lead

消费位点与当前分区最小位点的差距，我对该值的具体用途暂未参悟，有心的读者看到，欢迎与我共同交流。

1.3 消费者网络相关监控指标

上面的指标主要是关注消费端协调器、消费端Fetch(消息拉取)两个重要维度，接下来关注一下从消息者的视角关注一下底层网络IO等维度相关的指标，相关指标的采集入口位Kafka的org.apache.kafka.common.network.Selector,其具体的指标如下图所示：

其实这些指标基本与生产者相同，说明如下：

request-rate

请求发送tps。

request-size-max

请求发送的最大字节

request-size-avg

请求的平均大小

request-total

总共的请求个数