Лаг группы консюмеров всё растёт и никогда не догоняет. Определите причину по выводу состояния группы.
Группа консюмеров order-processor читает топик orders из 3 партиций. Сработали алерты: сквозная задержка растёт, лаг увеличивается. Запускаете команду describe и получаете:
$ kafka-consumer-groups.sh --bootstrap-server broker:9092 \
--group order-processor --describe
GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID
order-processor orders 0 4182233 4182240 7 consumer-1
order-processor orders 1 3120004 5987410 2867406 consumer-2
order-processor orders 2 - 6011882 6011882 -Объясните, почему растёт лаг, и предложите исправление.
Читайте лаг по партициям, не суммарно. У партиции 2 нет консюмера (CONSUMER-ID пуст): её лаг растёт безгранично — консюмеров меньше, чем партиций. Offset партиции 1 стоит: консюмер застрял на «отравленном» сообщении или медленный. Фикс: довести консюмеров до партиций и увести сообщение в DLQ.
- ✗Смотреть только суммарный лаг и упускать одну застрявшую или непривязанную партицию
- ✗Добавлять партиции вместо консюмеров, когда группе не хватает участников
- ✗Считать, что Kafka пропускает «отравленное» сообщение, а не повторяет его вечно
- →Почему партиция без назначенного консюмера копит лаг без ограничений?
- →Как коммит offset до обработки превращает «отравленное» сообщение в тихую потерю данных?
Читайте лаг по партициям, а не суммарно — три партиции ведут себя по-разному:
- Партиция 2 —
CONSUMER-IDпуст, аCURRENT-OFFSETравен-: её никто не читает. В группе меньше консюмеров, чем партиций, поэтому её лаг (6 011 882) растёт безгранично. - Партиция 1 —
consumer-2назначен, ноCURRENT-OFFSETпочти не двигается при лаге 2 867 406: консюмер застрял. Обычно это «отравленное» сообщение, на котором обработка падает и повторяется бесконечно, либо просто слишком медленный консюмер. - Партиция 0 — норма (лаг 7).
Исправление — добавить консюмеров до числа партиций и увести проблемное сообщение в DLQ:
# было 2 консюмера на 3 партиции → доводим до 3
kubectl scale deployment/order-processor --replicas=3
# после rebalance каждая партиция получает своего консюмера;
# «отравленное» сообщение после N повторов уходит в dead-letter topic,
# и партиция 1 снова разгребаетсяУвеличивать число партиций тут нельзя — это перехэширует ключи и сломает порядок по ключу.
