我正在阅读这个max.poll.records 如何影响消费者投票，以及 apache kafka docs，我仍然不确定是否fetch.min.bytes没有改变，默认为 1，kafka broker 是否有义务返回max.poll.records记录，如果有多少可用，或者没有？
根据我们的测试，即使某个主题中有足够的可用数据，它也不会总是返回那么多，并且文档中对该参数的解释及其纯粹的名称并不意味着它应该返回，但有些人倾向于相反的想法。我们还增加了可能防止这种情况发生的限制，例如message.max.bytes、max.message.bytes、max.partition.fetch.bytes和fetch.max.bytes（我们实际上不必增加，因为默认值相当高，50 MB），但这并没有改变任何事情。
我们也没有改变fetch.max.wait.ms，默认是500，也就是半秒，所以，如果fetch.min.bytes没有设置为大于1字节的东西，那么这个设置就生效了，即它决定了实际返回了多少条记录？这意味着如果max.poll.records返回的少于 then ，那是因为获取那么多需要 500 多毫秒？
我正在阅读这个问题Kafka：Continuously getting FETCH_SESSION_ID_NOT_FOUND，我正在尝试应用 Hrishikesh Mishra 建议的解决方案，因为我们也面临类似的问题，所以我增加了代理设置 max.incremental.fetch.session.cache.slots 到2000，默认为 1000。但现在我想知道如何监控已使用的增量获取会话缓存槽的实际数量，在 prometheus 中我看到 kafka_server_fetchsessioncache_numincrementalfetchpartitionscached 指标，并且 promql 查询在三个代理中的每一个上显示的数量现在明显超过 2000，那是 2703、2655 和 2054，所以如果我查看正确的指标，我会感到困惑。还有 kafka_server_fetchsessioncache_incrementalfetchsessionevictions_total 在所有代理上显示零。
好的，还有 kafka_server_fetchsessioncache_numincrementalfetchsessions 在三个代理中的每一个上显示 cca 500，所以总共 cca 1500，在 1000 和 2000 之间，所以也许该指标是由 max.incremental.fetch.session 控制的指标。缓存插槽？
其实截至目前，每个broker上已经有700多个增量fetch session，总共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
apache-kafka ×2