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

В прошлом уроке мы видели, как контроллер сам чинит кластер после падения брокера. Но одна беда приходит тихо и без ошибок в логах. Пятничным вечером Отто открывает табло статусов и видит заказ «создан», хотя курьер уже у двери клиента. Kafka работает, табло работает, просто табло не успевает. Сегодня про то, как это заметить раньше Отто.

Стопка писем на столе

Секретарь разбирает почту. Письма приносят в течение дня, и они ложатся стопкой на стол. Пока секретарь успевает, стопка маленькая. Если писем стало больше или секретарь отвлёкся, стопка растёт.

Начальнику не так важно, сколько писем лежит прямо сейчас: десять писем после обеда это нормально. Важно другое. Растёт ли стопка час за часом? И сколько ждёт самое старое письмо в ней? Если оно лежит с утра, кто-то уже недоволен.

У консьюмера Kafka тоже есть такая стопка.

Лаг

Лаг это число записей, которые группа ещё не обработала. Мы встречали его в уроке про оффсеты: конец партиции минус закоммиченный оффсет группы. Лаг считается для каждой партиции отдельно, и у каждой группы свой.

Смотрят его той же командой, что и закладки:

kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group status-board

В колонке LOG-END-OFFSET конец партиции, в CURRENT-OFFSET закладка группы, в LAG их разница. Если у группы нет закладки на партиции, в CURRENT-OFFSET и LAG стоит прочерк.

Лаг в записях удобно считать, но он не говорит главного: насколько табло отстаёт по времени. Сто записей у табло, которое обрабатывает тысячу записей в секунду, это доли секунды. Те же сто записей у обработчика, который думает над каждой секунду, это почти две минуты. Поэтому рядом с лагом в записях следят за лагом во времени: сколько ждёт самая старая необработанная запись.