Я читаю этот вопрос Кафка: постоянно получаю FETCH_SESSION_ID_NOT_FOUND , и я пытаюсь применить решение, предложенное Хришике sh Мишра, поскольку мы также сталкиваемся с подобной проблемой, поэтому я увеличил настройку брокера max.incremental.fetch.session.cache.slots до 2000, по умолчанию было 1000. Но теперь мне интересно, как я могу отслеживать фактическое количество используемых слотов кэша сеанса инкрементной выборки, в Прометее я вижу метрики kafka_server_fetchsessioncache_numincrementalfetchpartitionscached и запросы Promql отображаются на каждой из трех брокеров число, которое сейчас значительно превышает 2000, то есть 2703, 2655 и 2054, поэтому я запутался, если посмотрю на правильные метрики. Существует также kafka_server_fetchsessioncache_incrementalfetchsessionevictions_total, который показывает нули на всех брокерах.
ОК, есть также kafka_server_fetchsessioncache_numincrementalfetchsessions, который показывает 500 cca для каждого из трех брокеров, так что в сумме получается 1500 cca, что составляет от 1000 до 2000, так что, возможно, именно этот показатель контролируется max. incremental.fetch.session.cache.slots?
На самом деле, на данный момент это уже более 700 сессий инкрементной выборки для каждого брокера, то есть всего более 2100, поэтому, очевидно, предел 2000 применяется к каждому брокеру, поэтому число во всем кластере может составлять go до 6000. Причина, по которой число теперь меньше 1000 для каждого брокера, заключается в том, что брокеры были перезапущены после изменения конфигурации.
И вопрос в том, как это распределение можно проверить на уровне отдельного потребителя. Такой запрос:
count by (__name__) ({__name__=~".*fetchsession.*"})
возвращает только эту таблицу:
Element Value
kafka_server_fetchsessioncache_incrementalfetchsessionevictions_total{} 3
kafka_server_fetchsessioncache_numincrementalfetchpartitionscached{} 3
kafka_server_fetchsessioncache_numincrementalfetchsessions{} 3