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