当Kafka消息发送端遇到性能瓶颈时，有没有办法正确评估瓶颈在哪里？如何有针对性地进行优化？1.Kafka消息发送端其实Kafka已经为我们考虑好了监控指标。Kafka提供了丰富的监控指标，并提供了JMX方法来获取这些监控指标。客户端提供的监控指标如下图所示：主要监控指标分类如下：Producer-metrics为消息发送方的监控指标，其子节点均为进程下的生产者。Producer-node-metrics以Broker节点为维度，每个发送方的数据索引。producer-topic-metrics以topic为维度统计sender的一些指标。KafkaProducer相关的指标有很多，本文不再一一列举。1.1producer-metricsproducer-metrics是发送端非常重要的监控项，如下图：关键项解释如下：batch-size-avgSender时一个批次（ProducerBatch）的平均大小线程实际发送消息。batch-size-maxSenderthreadtime发送消息时批处理的最大大小。实用指导：个人认为收集这两个参数是非常有必要的。如果该值远小于batch.size设置的值，如果吞吐量达不到预期，可以适当增加linger.ms。batch-split-rateKafka提供了一种将大的ProducerBatch拆分成小的机制，即如果客户端的ProducerBatch超过了服务端允许的最大消息大小，就会在客户端触发拆分重发，这个值记录了每秒切割次数Ratebatch-split-totalKafka分割次数。温馨提示：根据笔者对这部分源码的阅读，我认为ProducerBatch的拆分意义不大，因为新分配的ProducerBatch的容量会等于batch.size，如果不超过这个大小,Batch不会被分割。这个功能很有可能无法完成实际的切割意图。实用指导：如果该值不为0，说明服务端和客户端设置的消息大小不合理。客户端设置的batch.szie大小应小于服务器设置的max.message.bytes。默认值为100W字节（约等于1M）buffer-available-bytes当前发送方缓冲区可用字节大小。buffer-total-bytes发送方缓冲区总大小，默认为32M，33,554,432字节。实践指导：如果缓冲区中的剩余字节数仍然很低，则需要评估缓冲区的大小是否合适。Sender线程遇到了瓶颈，所以要考虑网络和Broker是否遇到了瓶颈。bufferpool-wait-ratiobufferpool-wait-time-total客户端从缓存中请求内存以创建ProducerBatch块的总时间。实用指导：如果该值持续大于0，说明发送存在瓶颈。可以适当降低linger.ms的值，让消息有机会得到更及时的处理。produce-throttle-time-avg受broker流量限制的平均发送消息时间produce-throttle-time-max受broker限制的最大发送消息时间io-ratioIO线程处理的总时间IO读写io-time-ns-avg每个事件选择器调用一次IO操作的平均时间（以纳秒为单位）。io-waittime-totalio线程等待读写就绪的平均时间（以纳秒为单位）。iotime-totalio的总处理时间。network-io-rate客户端网络每秒读取和写入所有连接的tps。network-io-total客户端所有连接上的网络操作（读取或写入）总数。1.2通用指标除了上述消息发送端的指标外，Kafka还有一些通用的监控指标。这些指标的统计维度包括：消息发送者、节点、TOPIC三个维度。主要维度描述如下：producer-meticssender维度producer-node-metricssender-broker节点维度producer-topic-metricssender-topic维度statistics接下来描述的metrics是在不同的维度上统计的，但是表达的意思是一样的，所以下面统一描述。incoming-byte-rateIncomingtrafficpersecond，每秒传入的字节数。incoming-byte-total传入字节总数。outgoing-byte-total总计发送的字节数。发送request-latency-avg消息的平均延迟。request-latency-max消息发送的最大延迟时间。实用指导：latency-avg和max可以反映消息发送的延迟性能。如果延迟太高，说明Sender线程发送消息有瓶颈。建议将此值与linger.ms进行比较。如果该值明显小于linger.ms，那么为了提高吞吐率，可以适当调整batch.size的大小。request-rate每秒发送Tpsrequest-size-avg发送的消息的平均大小。request-size-maxSender线程发送的单个消息的最大大小。实用指导：如果该值小于max.request.size，说明客户端积压的消息不多。如果其他维度遇到瓶颈，可以使用合适的linger.ms和batch.size，有效提升吞吐量。request-total请求发送的字节总数response-rate每秒从服务器接收到的TPS响应总数。response-total从服务器接收到的响应总数。2.监控指标的收集虽然Kafka内置了很多监控指标，但是这些指标默认是保存在内存中的。由于是存储在内存中，为了避免监控数据不断增加导致内存溢出，通常监控数据的存储基本上是基于滑动窗口的，即只存储最近的监控数据将存储一段时间用于滚动覆盖。因此，为了更直观地显示这些指标，由于需要定期收集信息并存储在其他数据库和其他持久性存储中，因此可以根据历史数据绘制曲线。想要的效果如下图：基本监控采集系统架构设计如下图：mq-collect放在producerSDK中，采集到的信息会异步上传到时序数据库InfluxDB并定期通过mq-collect类库，然后通过mq-portal门户进行页面展示，为每个生产客户终端可以根据指标进行可视化展示，实现监控数据的可视化，从而提供依据用于性能优化。本文转载自微信公众号“中间件兴趣圈”，可通过以下二维码关注。转载本文请联系感兴趣的中间件圈公众号。
