作为Kafka集群的负责人，当消费者端出现消息积压，反复rebalancing等问题时，如何快速定位性能瓶颈非常重要。本文将详细介绍端到端的消费者监控指标，为架构师提出的性能优化方案提供数据支持。Kafka的设计者已经为我们考虑好了，提供了多种监控指标。1、consumerindicatorKafka中的监控指标是通过MBeans存储的，我们可以通过jconsole查看。截图如下：主要分为以下四个维度：Consumer-coordinator-metricsConsumer组协调器相关的监控指标。consumer-fetch-manager-metricsconsumer-fetch-manager-metrics消费组消息拉取相关监控指标Consumer-node-metrics统计broker节点维度的信息，消费端从多个broker节点拉取消息等监控指标。接下来Kafka-metrics-count将单独展开，详细介绍各个指标的含义，并给出一些实用指导。1.1消费者组协调器监控指标组协调器相关的监控指标具体如下：详细说明如下：join-time-max消费者重新加入消费者组的最长时间join-time-avg消费者重新加入消费者组的平均时间重新加入消费群join-rate消费者加入消费群TPS实践指导：0值为正常，数值越大越有问题，说明消费者频繁加入消费者，消费者不会加入消费群加入消费者消费新闻的过程。join-time-avg消费者加入消费者组的平均时间join-total消费者重新加入消费者组的次数（重新平衡发生的次数）。balance次数过多，consumer在rebalancing时不参与消息消费。commit-latency-avg提交站点的平均时间commit-rate提交站点的tpscommit-latency-max提交站点时的最大延迟时间commit-total自消费者开始以来站点提交的总数sync-time-avg消费者发送同步的平均响应时间。知识点：consumer加入group后，consumer中的Leader负责队列分配，然后将分配方案发送给groupprotocol，各个slave节点会从groupcoordinator获取分配队列。sync-rate消费者发送同步的tpssync-total消费者发送的同步请求总数sync-time-max消费者同步请求响应的最大响应时间assigned-partitions当前分配的分区数heartbeat-total心跳请求总数heartbeat-response-time-max心跳请求的最大响应时间last-heartbeat-seconds-ago上次发送心跳包的时间职责：协调消费者加入消费者组协调消费者领袖分配队列负载发送心跳和维护会话提交点拉取指标的组织分为两个维度：消费者组和消费者组订阅的多个主题。接下来详细分析以上指标：bytes-consumed-rate消费者每秒向业务提交的tps。bytes-consumed-total消费者当前消耗的字节总数。fetch-latency-maxAPI.FETCH请求（即发送消息给broker拉取）的最大耗时。records-per-request-avg每次Fetch请求拉取的消息数量（当前索引的平均值）。fetch-rate客户端发送Fetch请求的tps。fetch-total客户端探索发起的Fetch请求总数。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-lagrecords-lag-avgrecords-lag-maxrecords-leadrecords-lead-avgrecords-lead-min以上Indicators主要解释两个基本含义，其他指标聚合并计算（最大值，平均值）。records-lag消费积压，即消费位置与当前分区最大位置的差距。该值越大，消费端的处理速度越慢，需要引起高度重视。平时需要连接报警器，及时通知项目方。records-leadconsumptionpoint和当前分区的最小点之间的差距，这个值的具体用途我还没有弄明白，欢迎有兴趣的读者和我交流。1.3消费者网络相关监控指标以上指标主要关注消费者端协调器和消费者端Fetch（消息拉取）两个重要维度。接下来从messager的角度重点关注底层网络IO等维度的指标，相关指标的集合入口是Kafka的org.apache.kafka.common.network.Selector，其具体指标如下图所示：其实这些指标和producers基本一样，说明是如下：request-rate请求发送tps。request-size-max请求发送的最大字节request-size-avg请求的平均大小request-total请求总数select-rate事件选择器tps。select-total事件选择器执行事件选择的总次数response-total响应请求总数response-rateResponseTPSoutgoing-byte-rate每秒发送的字节数outgoing-byte-total总数bytessent接受的字节数，单位秒incoming-byte-total总worker接受的字节数io-ratioIO线程处理IO读写的总时间调用IO操作的事件选择器（以纳秒为单位）io-waittime-totalio线程等待读写准备就绪的平均时间（以纳秒为单位）iotime-totalio总处理时间。io-wait-ratioio等待占io总处理时间的比例io-wait-time-ns-avgio线程平均等待时间（纳秒）实用指导：对于网络相关的监控指标，可以关注与性能相关的io线程。1.4broker节点采集监控数据客户端也会根据broker的维度重点采集请求相关的指标，比如请求tps、平均响应时间等。实践指导：监控指标的含义上面已经说了，这些指标应该是最值得收集的，尤其是request-latency-max，request-latency-avg，对于确认broker是否存在瓶颈很有用。2.监控指标的收集虽然Kafka内置了很多监控指标，但是这些指标默认是保存在内存中的。由于是存储在内存中，为了避免监控数据不断增加导致内存溢出，通常监控数据的存储基本上是基于滑动窗口的，即只存储最近的监控数据将存储一段时间用于滚动覆盖。因此，为了更直观地显示这些指标，由于需要定期收集信息并存储在其他数据库和其他持久性存储中，因此可以根据历史数据绘制曲线。想要的效果如下图所示：此处插入一张图片来描述基本情况监控采集系统的架构设计如下图所示：mq-collect应该放在producerSDK中，采集到的信息将通过mq-collect类库异步定时上传到时序数据库InfluxDB，然后通过mq-portal入口展示页面。将各个生产客户端按照指标进行可视化展示，实现监控数据的可视化，为性能优化提供依据。本文转载自微信公众号“中间件兴趣圈”，可通过以下二维码关注。转载本文请联系感兴趣的中间件圈公众号。
