Мониторинг и эксплуатация: лаг консьюмера

Урок про то, как понять, что с кластером и потребителями всё хорошо — или плохо.

Consumer lag — разница между последним оффсетом в партиции и оффсетом, до которого дочитал консьюмер; это главный индикатор того, поспевает ли обработка за потоком.

Зачем это нужно

Kafka может работать идеально, а данные всё равно «опаздывать» — если консьюмер не успевает читать. Лаг показывает это раньше всех симптомов: он растёт — значит, поток событий обгоняет обработку, и реальное время превращается в «через час». Мониторинг лага — первое, что настраивают на проде.

Что такое лаг

  Партиция P0:  [....................] последний оффсет = 10000
  Консьюмер дочитал до оффсета     = 9300
  lag = 10000 - 9300 = 700 событий отставания

  lag стабилен/около нуля -> поспеваем
  lag растёт во времени   -> не успеваем (узкое место)
# показать лаг группы по всем партициям
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --describe --group billing

Вывод:

TOPIC   PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG
orders  0          9300            10000           700
orders  1          8800            8800            0
orders  2          12010           12050           40

Ключевые метрики

МетрикаО чём говорит
consumer lagпоспевает ли обработка за потоком
under-replicated partitionsреплики отстают/брокер болеет
request latency (produce/fetch)задержки записи/чтения
rebalance rateчастота ребалансов (штормы — плохо)
bytes in/out per secпропускная способность брокеров

Ребаланс-штормы

Если группа постоянно ребалансируется, чтение всё время прерывается и лаг растёт. Причина обычно — консьюмеры «выпадают»: обработка одного poll-цикла дольше max.poll.interval.ms, и координатор считает их зависшими. Лечится уменьшением max.poll.records, ускорением обработки или выносом тяжёлой работы из poll-цикла.

Как работает под капотом

Лаг считается на лету: LOG-END-OFFSET берётся у партиции, CURRENT-OFFSET — из __consumer_offsets группы; разность и есть отставание. Поэтому лаг точен лишь настолько, насколько свежи коммиты оффсетов — редкий коммит даёт «пилу» в графике лага. Under-replicated partitions сигналят, что фолловеры не успевают за лидером (перегрузка, медленный диск, сетевые проблемы) — это предвестник риска при сбое. Здоровый кластер: лаг стабилен, under-replicated = 0, ребалансы редки, латентность ровная без длинных хвостов.

Частые ошибки

  • Не мониторить лаг. Узнать о «отставании на сутки» от пользователей — худший вариант.
  • Реагировать на средние, а не на тренд. Важно, что лаг растёт, а не его абсолютное мгновенное значение.
  • Игнорировать under-replicated partitions. Это тихий предвестник потери данных при следующем сбое.

Итоги

  • Consumer lag — главная метрика: растёт — обработка не поспевает за потоком.
  • Следят также за under-replicated partitions, латентностью, частотой ребалансов и пропускной способностью.
  • Ребаланс-штормы обычно от долгой обработки в poll-цикле; лечатся ускорением и настройкой poll.
Проверьте себя
1. Что такое consumer lag?
AВремя жизни сообщения
BРазница между последним оффсетом партиции и оффсетом, до которого дочитал консьюмер
CЧисло партиций
DРазмер батча
2. На что важнее смотреть в лаге?
AНа абсолютное мгновенное значение
BНа тренд: растёт ли лаг со временем
CНа цвет графика
DЛаг не важен
3. Что обычно вызывает ребаланс-штормы?
AСлишком много партиций
BОбработка одного poll-цикла дольше max.poll.interval.ms — консьюмеров считают зависшими
CВключённое сжатие
DМалый retention