Мы используем Kafka Streams для некоторой обработки потоков и видим странные журналы в нашей системе наблюдения.
Все работает и обработка работает без проблем, но журнал INFO немного беспокоит.
Вот наше определение потока
@Bean
public KTable < Long, String > kStream(StreamsBuilder streamsBuilder) {
KStream < Long, String > stream1 = streamsBuilder.stream(topic1);
KStream < Long, String > stream2 = streamsBuilder.stream(topic2);
stream1.merge(stream2)
.selectKey((userId, v) - > userId)
.groupByKey()
.aggregate(
CustomObject::new,
(aggKey, newValue, aggValue) - > aggValue.aggregate(newValue),
Materialized
. < Long, OutputObject, KeyValueStore < Bytes, byte[] >> as(storeName)
.withKeySerde(Serdes.Long())
.withValueSerde(outputCustomSerde)
.withStoreType(Materialized.StoreType.IN_MEMORY)
.withCachingDisabled()
)
.toStream()
.to(topic3);
return null;
}
На основе определения потока создаются 2 темы Kafka — одна changelog
и одна repartition
.
Вот 3 информационных журнала, которые мы получаем:[AdminClient clientId=test-kafka-streams-v2-ade9efd5-bf02-4f98-baf7-97db2bfcb2ef-admin] Cancelled in-flight DELETE_RECORDS request with correlation id 1780227 due to node 1 being disconnected (elapsed time since creation: 3ms, elapsed time since send: 3ms, request timeout: 2ms)
[AdminClient clientId=test-kafka-streams-v2-ade9efd5-bf02-4f98-baf7-97db2bfcb2ef-admin] Cancelled in-flight METADATA request with correlation id 1845715 due to node 1 being disconnected (elapsed time since creation: 19ms, elapsed time since send: 19ms, request timeout: 18ms)
[AminClient clientId=test-kafka-streams-v2-ade9efd5-bf02-4f98-baf7-97db2bfcb2ef-admin] Disconnecting from node 1 due to request timeout.
Наш вопрос: стоит ли нам беспокоиться об этих трех журналах?
Если да, то что мы можем с этим поделать?
Если нет, то стоит ли как-то подавить это или просто игнорировать?
Большое спасибо
стоит ли нам беспокоиться об этих трёх бревнах
Нет. Клиент администратора просто повторно подключится и повторит попытку.
стоит ли нам как-то подавить это или просто игнорировать?
Я бы просто проигнорировал это. Конечно, вы также можете изменить уровень журнала.
Не уверен... но мне все равно интересно. В конце концов, при каждом коммите KS должен использовать клиент администратора для очистки данных из темы перераспределения - учитывая интервал фиксации по умолчанию 30 секунд и тайм-аут соединения по умолчанию 5 минут, я не уверен, почему соединение закрывается... Я думаю, вы могли бы попробовать использовать больший тайм-аут соединения для клиента администратора?
Какой параметр я могу использовать, чтобы увеличить время ожидания соединения для клиента администратора? Довольно странно, что эти журналы являются постоянными каждые несколько минут, но не вызывают никаких реальных проблем с приложением.
Есть ли какие-либо параметры KafkaStreams, которые вы бы порекомендовали настроить, чтобы можно было исправить эти журналы INFO?