我正在读这个问题Kafka。持续得到FETCH_SESSION_ID_NOT_FOUND
,因为我们也面临类似的问题,所以我把broker的设置max.incremental.fetch.session.cache.slots
增加到2000
,默认是1000
。但现在我想知道如何才能监控已使用的增量获取会话缓存槽的实际数量,在Prometheus中,我看到kafka_server_fetchsessioncache_numincrementalfetchpartitionscached
指标,而promql查询显示在三个broker中的每一个都明显超过2000,即2703,2655和2054,所以我很困惑,如果我看的是正确的指标。还有kafka_server_fetchsessioncache_incrementalfetchsessionevictions_total
在所有broker上显示为零。
好吧,还有kafka_server_fetchsessioncache_numincrementalfetchsessions,在三个broker上各显示500个,所以总共是1500个,在1000和2000之间,所以也许这个指标是由max.incremental.fetch.session.cache.slots
控制的?
实际上,到现在为止,每个broker上的增量获取会话已经超过了700个,也就是总共超过了2100个,所以,很明显,2000的限制适用于每个broker,所以整个集群中的数量可以达到6000。之所以现在每个broker的数量低于1000,是因为配置改变后broker被重新启动了。
问题是如何单独在消费者层面检查这种分配,这样的查询:
count by (__name__) ({__name__=~".*fetchsession.*"})
只返回这个表:
Element Value
kafka_server_fetchsessioncache_incrementalfetchsessionevictions_total{} 3
kafka_server_fetchsessioncache_numincrementalfetchpartitionscached{} 3
kafka_server_fetchsessioncache_numincrementalfetchsessions{} 3