Мониторинг и эксплуатация: лаг консьюмера
Урок про то, как понять, что с кластером и потребителями всё хорошо — или плохо.
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.