我正在读这个问题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
名为
kafka.server:type=FetchSessionCache,name=NumIncrementalFetchSessions的指标是监控FetchSessions数量的正确方法。大小可以通过
max.incremental.fetch.session.cache.slots来配置。请注意，这个设置是按broker应用的，所以每个broker最多可以缓存max.incremental.fetch.session.cache.slots会话。你看到的另一个指标，
kafka.server:type=FetchSessionCache,name=NumIncrementalFetchPartitionsCached，是所有FetchSession中使用的分区总数。许多FetchSessions会使用几个分区，所以预计会看到一个较大的数量。正如你所说的，你看到的低数量的FetchSessions可能是由于重新启动。
你的答案