Мониторинг: лаг консьюмера

Формула лага двухсложная. У каждой партиции есть лог с последним офсетом — high watermark, число записей, которое брокер уже принял. У консьюмера есть собственная позиция — офсет последнего разобранного сообщения, который он же и коммитит. Лаг партиции равен разности: последний офсет минус текущий офсет группы. Ридер без GroupID из четырнадцатого урока хранит эту позицию сам, групповой консьюмер из седьмого — в координаторе, но смысл числа одинаков: столько событий легло в топик, а в хендлер ещё не попало. Из формулы следуют обе стороны жизни лага. Растущий лаг означает, что в единицу времени в партицию пишется больше, чем консьюмер успевает разобрать: не хватает партиций, упала скорость хендлера, задерживает внешняя система. Отрицательного лага не бывает, а вот лаг, застрявший на нуле, — не всегда победа: он говорит лишь, что очередь пуста в момент замера, и ничего — о том, жив ли сам потребитель и коммитит ли он позиции. Именно поэтому лаг смотрят в динамике, а не одним срезом, и всегда вместе с признаками жизни процесса.

В сыром виде лаг — штуки, и порог «лаг больше тысячи» ничего не значит: для топика с десятью событиями в сутки это осень, для платежного потока — полминуты. Kafka lag мониторинг начинается с перевода лага во время: лаг, умноженный на среднюю скорость обработки одной партиции, даёт минуты задержки, и алерт ставится именно на задержку — «фоновая обработка отстаёт больше чем на пять минут». Второй обязательный график — скорость изменения лага. После деплоя лаг, выросший ступенькой и вернувшийся к нулю, означает паузу на рестарт и ребаланс из тринадцатого урока; лаг, выросший и не возвращающийся, означает, что новый код медленнее старого. Ноль, продержавшийся часы при живом потоке продюсера, — тоже не повод для радости, а сигнал смотреть коммиты: либо консьюмер перечитывает то же место с кривым стартовым офсетом, либо коммиты задерживаются, и позиция группы врёт. Отдельно честный вывод: единственного числа «лаг» мало — мониторят лаг, скорость его роста и факт коммитов, и только связка этих линий отличает живую систему от тихо заглохшей.

Ограничение из квиза — не досадная недоделка, а следствие архитектуры. Ридер без GroupID знает свою позицию сам: он хранит текущий офсет в памяти и потому способен посчитать лаг в один запрос. Групповой консьюмер из седьмого урока позицию не выбирает — её назначает координатор, коммиты лежат в брокере, и после ребалансировки партиции переехали бы к другим членам в любой момент. Число в памяти отдельного Reader ничего бы не значило, поэтому kafka-go возвращает errNotAvailableWithGroup, а Lag() — минус единицу. Что делать, если поток живёт группой, а лаг видеть нужно? Три пути. Первый — снять статистику топика напрямую через Client: разность последнего офсета партиции и закоммиченного офсета группы, метод, который мы разберём в восемнадцатом уроке про контексты и таймауты. Второй — вывести лаг на сторону брокера: kafka-lag-exporter и консольные утилиты кластера считают его из коммитов. Третий — держать для наблюдения отдельный ридер без GroupID, читающий тот же топик с LastOffset: он не мешает группе, потому что не состоит в ней. Практическое правило: ReadLag — для ручных и тестовых потоков, групповой лаг — за пределами kafka-go, в метриках кластера.

Лаг, который смотрят руками, мониторингом не является: его забудут посмотреть именно в тот вечер, когда он вырастет. Паттерн фонового мониторинга — отдельная горутина с тикером, живущая в контексте приложения. Она периодически снимает лаг всех наблюдаемых ридеров и партиций, пишет его в лог или отправляет в систему метрик, и умирает вместе с контекстом, не оставляя утечек. Три детали делают горутину рабочей, а не декоративной. Во-первых, свой таймаут на каждый замер: ReadLag ходит в брокер, и замер не должен зависеть от чужих таймаутов — приёмы из восемнадцатого урока. Во-вторых, ошибка замера — тоже метрика: недоступный брокер для мониторинга выглядит как всплеск ошибок, а не как ноль лага, иначе дежурный увидит обманчивое благополучие. В-третьих, замер должен обходить все партиции потока, а не одну. Занятно, что внутри Reader уже живёт похожая механика: ReadLagInterval запускает фоновую горутину, которая с тикером обновляет кэш для Lag(), — наш паттерн повторяет её, но во внешний мир. Для Async-Writer из десятого урока та же горутина снимает Stats: без неё ошибки записи невидимы в принципе.

Арифметика алерта: средняя скорость обработки партиции — десять событий в секунду, лаг пять тысяч — восемь минут задержки. Порог настраивается на время, а не на штуки: «задержка больше пяти минут в течение трёх проверок подряд» — правило, которое не сработает от случайного всплеска и не промолчит при реальном отставании. Второе правило — ступенька после деплоя: короткий рост лага на рестарте с последующим возвратом к нулю — норма ребаланса; рост, который не возвращается за таймаут выката, открывает инцидент ещё до жалоб пользователей. Третье — зеркальный алерт на подозрительный ноль при живом продюсере: он ловит и застрявший консьюмер, и задержавшиеся коммиты, потому что и то и другое выглядит как позиция, не двигающаяся с места. Свяжем с ошибками чтения: если лаг растёт вместе с ретраями и ошибками из девятнадцатого урока, потребитель не медленный, а падающий — яд-сообщение, от которого группа циклится, живёт в списке пунктов о ядовитых сообщениях. Мониторинг лага без мониторинга ошибок чтения половину таких случаев примет за «просто не успеваем».