У меня есть приложение на стороне сервера, написанное на Go, которое создает события Kafka.Он отлично работает в течение нескольких дней, производя ~ 1.6k msg / sec, а затем сталкивается со спорадической проблемой, когда все сообщения Kafka останавливаются, а приложение сервера необходимо перезапустить вручную, чтобы сообщения Kafka возобновили отправку.
Я включил скриншот метрических графиков, когда инцидент начался.Чтобы прокомментировать происходящее:
В течение семи дней приложение работает отлично.Для каждого сообщения в очереди есть уведомление о доставке, отправленное на kafkaProducer.Events().Вы можете видеть, что num в очереди = num доставлено.
10: 39: проблема начинается.Количество уведомлений о доставке быстро падает до нуля.Сообщения Kafka продолжают ставиться в очередь, но обратные вызовы прекращаются.
10: 52: kafkaProducer.ProduceChannel() заполняется, и попытки поставить в очередь новые сообщения в канал go блокируют выполнение процедуры.На этом этапе приложение никогда не отправит еще одно сообщение Kafka, пока оно не будет перезапущено вручную.
17: 55: я перезапустил приложение вручную.очередь сообщений кафки / доставка возобновляется.kafka_produce_attempts возвращается к нулю.
Единственное место, куда мой код Go отправляет сообщения Kafka, находится здесь:
recordChannelGauge.Inc()
kafkaProducer.ProduceChannel() <- &msg
recordChannelGauge.Dec()
На метрическом скриншоте обратите внимание, что recordChannelGauge обычно остается равным нулю, потому что отправка сообщения в Kafka ProduceChannel() не блокируется, и за каждым Inc() сразу следует соответствующее Dec() Однако, когда ProduceChannel() заполнен, блокировка программы и recordChannelGauge остается на 1 и никогда не разблокируется, пока приложение не будет перезапущено вручную.
К вашему сведению, подробности моей среды:
- Двоичный сервер Go, созданный с использованием golang 1.10.x
- Последняя версия
github.com/confluentinc/confluent-kafka-go/kafka.Эта библиотека не использует версии, она использует последнюю версию git commit, которой на момент написания статьи уже 2 месяца, поэтому я уверен, что использую эту последнюю версию. - Серверная ОС Ubuntu 16.04.5
- librdkafka1 версия librdka0.11.6 ~ 1confluent5.0.1-
Я подозреваю, что это связано с некоторой внутренней проблемой в клиенте confluentinc go, где он не обрабатывает некоторые ошибки соответствующим образом.
Кроме того, я не вижу соответствующих выходных данных журнала во время проблемы.Я вижу, что спорадический брокер Kafka отключен и тайм-аут ошибок в журналах до возникновения проблемы, которая не кажется серьезной.Эти сообщения журнала происходили каждые несколько часов или около того в течение нескольких дней без серьезных последствий.
Nov 26 06:52:04 01 appserver.linux[6550]: %4|1543215124.447|REQTMOUT|rdkafka#producer-1| [thrd:kafka-broker-3:9092/bootstrap]: kafka-broker-3:9092/bootstrap: Timed out 0 in-flight, 1 retry-queued, 0 out-queue, 0 partially-sent requests
Nov 26 06:52:10 01 appserver.linux[6550]: %4|1543215130.448|REQTMOUT|rdkafka#producer-1| [thrd:kafka-broker-3:9092/bootstrap]: kafka-broker-3:9092/bootstrap: Timed out 0 in-flight, 1 retry-queued, 0 out-queue, 0 partially-sent requests
Nov 26 08:46:57 01 appserver.linux[6550]: 2018/11/26 08:46:57 Ignored event: kafka-broker-2:9092/bootstrap: Disconnected (after 600000ms in state UP)
Nov 26 08:47:02 01 appserver.linux[6550]: %4|1543222022.803|REQTMOUT|rdkafka#producer-1| [thrd:kafka-broker-2:9092/bootstrap]: kafka-broker-2:9092/bootstrap: Timed out 0 in-flight, 1 retry-queued, 0 out-queue, 0 partially-sent requests
Nov 26 08:47:09 01 appserver.linux[6550]: %4|1543222029.807|REQTMOUT|rdkafka#producer-1| [thrd:kafka-broker-2:9092/bootstrap]: kafka-broker-2:9092/bootstrap: Timed out 0 in-flight, 1 retry-queued, 0 out-queue, 0 partially-sent requests
Увеличено до возникновения проблемы
Уменьшено, чтобы показать до и после
