我一直在监视由4台机器组成的kafka集群上的指标。我有一个输入应用程序将消息写入kafka，还有几个kafka流应用程序处理这些消息，并将它们写回一个由地理位置变量划分的新kafka主题。
集群将在一段不确定的时间（通常是两天或三天）内无任何问题地运行，在度量中没有任何可疑的报告，然后不知从哪里得到度量 kafka.network:type=RequestChannel,name=RequestQueueSize 将从不超过10个请求的最大值增加到50或60个请求，但仅在单个代理上。这最终会导致kafka流中的producer请求队列在几分钟内建立并超时（目前我没有复制主题）。
此外，如果我重新启动streams应用程序，代理请求队列会很快再次建立起来。
它似乎涉及到特定的请求，但不是所有的请求都是基于一个高的第99百分位数 kafka.network:type=RequestMetrics,name=RequestQueueTimeMs （约为2秒），但平均值较低（约为0.3毫秒）。
cpu使用是正常的，即没有达到硬限制。
是什么原因导致经纪人这样变得不健康？我是否应该考虑其他指标？
1条答案
按热度按时间8fsztsew1#
如果您遇到性能突然下降或cpu空闲超时，您可能正在处理io问题。
最好的衡量标准之一是
kafka.log:type=LogFlushStats,name=LogFlushRateAndTimeMs. 如果您看到日志刷新率或日志刷新延迟增加，则表示kafka在写入磁盘时遇到问题。在我们的例子中，页面缓存被刷新的频率太高，导致写入iops激增，而平均io请求大小下降。因为我们使用的是具有突发平衡的ebs示例，所以重复的写操作耗尽了我们的突发存储桶，并导致请求队列建立。