我一直在监控4台机器的Kafka集群上的指标。我有一个输入应用程序将消息写入Kafka和几个Kafka Streams应用程序处理这些消息并将它们写回由地理定位变量分区的新Kafka主题。
群集将在不确定的时间内（通常为两天或三天）运行没有任何问题，在度量标准中没有任何可疑的报告，然后不知何时度量标准kafka.network:type=RequestChannel,name=RequestQueueSize将从不超过10个请求的最大值中飙升50或60个请求，但仅限于一个经纪人。这最终导致Kafka Streams中的生产者请求队列在几分钟内建立并超时（此时我还没有复制主题）。
此外，如果我重新启动Streams应用程序，代理请求队列将再次快速建立。
看起来它涉及特定的请求，但并非所有这些请求基于kafka.network:type=RequestMetrics,name=RequestQueueTimeMs的高第99百分位数（大约2秒）而是低平均值（大约0.3毫秒）。
CPU使用率是正常的，即没有达到硬限制。
经纪人可能以这种方式变得不健康的原因是什么？我应该关注其他指标吗？
如果您遇到性能突然下降或CPU闲置超时，那么您可能正在处理IO问题。
要查看的最佳指标之一是kafka.log:type=LogFlushStats,name=LogFlushRateAndTimeMs。如果您看到日志刷新率或日志刷新延迟增加，则意味着Kafka在写入磁盘时遇到问题。
在我们的例子中，我们的页面缓存被过于频繁地刷新，导致我们的写入iops在我们的平均io请求大小下降时出现峰值。由于我们使用具有突发平衡的EBS实例，因此重复写入会耗尽我们的突发桶并导致我们的请求队列建立。