Kafka中的这只“千里眼”，你需要知道！！！_fetch-latency-max

消费者发送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

总共的请求个数

• select-rate

事件选择器tps。

• select-total

事件选择器执行事件选择的总次数

• response-total

响应请求总数

• response-rate

响应TPS

• outgoing-byte-rate

每秒发送字节数

• outgoing-byte-total

总发送字节数

• incoming-byte-rate

每秒接受字节数

• incoming-byte-total

总工接受字节数

• io-ratio

IO线程处理IO读写的总时间

• io-time-ns-avg

每一次事件选择器调用IO操作的平均时间(单位为纳秒)

• io-waittime-total

io线程等待读写就绪的平均时间（单位为纳秒）

• iotime-total

io处理总时间。

• io-wait-ratio

io等待占io总处理时间的比例

• io-wait-time-ns-avg

io线程平均等待时间（纳秒）

实战指导：网络相关的监控指标，可以重点关注一下io线程相关的性能。

1.4 按broker节点采集监控数据

客户端还会按照broker的维度，重点采集与请求相关的指标，例如请求tps、平均响应时间。

实战指导：监控指标的含义都已经在上文中提到过，这些指标应该是最值得采集，特别是request-latency-max、request-latency-avg，这对确认broker是否存在瓶颈。

2、监控指标采集

---

虽然Kafka内置了众多的监控指标，但这些指标默认是存储在内存中，既然是存放在内存中，为了避免监控数据无休止的增加内存触发内存溢出，通常监控数据的存储基本是基于滑动窗口，即只会存储最近一段时间内的监控数据，进行滚动覆盖。

故为了更加直观的展示这些指标，因为需要定时将这些信息进行采集，统一存储在其他数据库等持久化存储，可以根据历史数据绘制曲线，希望实现的效果如下图所示：

基本的监控采集系统架构设计如下图所示：

mq-collect应该是放在生产者SDK中，通过mq-collect类库异步定时将采集信息上传的到时序数据库InfluxDB,然后通过mq-portal门户展示页面，对每一个生产客户端按指标进行可视化展示，实现监控数据的可视化，从而为性能优化提供依据。

---

好了，本文就介绍到这里了，一键三连(关注、点赞、留言)是对我最大的鼓励。

掌握一到两门java主流中间件，是敲开BAT等大厂必备的技能，送给大家一个Java中间件学习路线，助力大家早日进入互联网大厂。

Java进阶之梯，成长路线与学习资料，助力突破中间件领域

最后分享笔者一个硬核的RocketMQ电子书，您将获得千亿级消息流转的运维经验。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

总结

这个月马上就又要过去了，还在找工作的小伙伴要做好准备了，小编整理了大厂java程序员面试涉及到的绝大部分面试题及答案，希望能帮助到大家

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
ages/e5c14a7895254671a72faed303032d36.jpg" alt=“img” style=“zoom: 33%;” />

总结

这个月马上就又要过去了，还在找工作的小伙伴要做好准备了，小编整理了大厂java程序员面试涉及到的绝大部分面试题及答案，希望能帮助到大家

[外链图片转存中…(img-B2FHeHse-1713212429052)]

[外链图片转存中…(img-05WsXSJm-1713212429053)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！