Грабли продакшена Kafka

Symptom: одна партиция топика горит под стопроцентной загрузкой, соседние стоят на нуле, а пропускная способность топика равна мощности одной партиции вместо двенадцати. Причина — в балансере: Hash считает хеш ключа и всегда отправляет одинаковый ключ в одну партицию; крупный тенант, системный сервис-источник или любой другой перекос в данных наполняет именно его отсек, а RoundRobin, который размазывал бы равномерно, в этой конфигурации не участвует. Диагностика быстрее всего по разрезу лага и загрузки на партиции: перекос виден в первые минуты, тогда как общий график топика остаётся благополучным, пока горит хотя бы один отсек. Лечения три, по ситуации. Сменить ключ на более гранулярный, если порядок по старому ключу не нужен, — самое дешёвое. Просолить ключ детерминированной добавкой и получить партиций на ключ несколько — работоспособно, но ломает порядок внутри ключа, поэтому годится только там, где порядок не требовался. Добавить партиций — так ли это лечение: CreatePartitions умеет только увеличивать число, и после увеличения маппинг ключа в партицию пересчитается, то есть порядок по ключу сломается для всех существующих отправителей; партиции расширяют заранее, под рост, а не после инцидента.

Symptom: после падения сервиса часть событий обработана дважды — или, хуже, исчезла. Причина одна: строка CommitMessages стоит не на своём месте, а гарантия доставки целиком задаётся этим местом, о чём девятый урок говорил в терминах at-least-once и at-most-once. Автокоммит с CommitInterval больше нуля коммитит фоново по расписанию: упал процесс — недокоммиченный хвост перечитается, это at-least-once с возможными дублями. Синхронная схема с CommitInterval равным нулю честнее: коммит — это явный вызов, и его позиция определяет гарантию. Коммит после успешной обработки — at-least-once: падение между обработкой и коммитом означает перечитывание и дубликат, который гасится идемпотентностью по бизнес-ключу. Коммит до обработки — at-most-once: падение после коммита теряет событие навсегда, потому что группа уже двинулась дальше. Дешёвого варианта нет — есть выбор между дубликатами и потерями, и осознанный выбор делают до инцидента, а не во время. Проверьте свой код прямо сейчас: одна строка CommitMessages, её позиция относительно process и знание, что произойдёт при падении между ними, — это вся дисциплина коммитов, остальное — следствия.

Symptom: консьюмеры циклятся — группа собирается, начинает обрабатывать, расцепляется и собирается снова, дубли множатся на каждом витке. Причина — арифметика членства: координатор считает консьюмера живым, пока тот шлёт heartbeats, и инициирует ребаланс, когда heartbeat замолкает на SessionTimeout. В kafka-go heartbeat идёт из фонового механизма группы с настраиваемым HeartbeatInterval — три секунды по умолчанию, — поэтому долгий хендлер сам по себе не выкидывает читателя из группы, как это случалось в клиентах, где пул совмещён с опросом. Но эффект рядом: пока хендлер держит пачку, коммиты стоят на месте, лаг растёт, а любая причина ребаланса — рестарт соседа, изменения в топике — отдаёт недоделанную работу другому консьюмеру, и тот перечитывает её с последнего закоммиченного офсета. Лечение структурное: хендлеры короче — батчи меньше и чаще; SessionTimeout и HeartbeatInterval задаются явно с запасом под реальный профиль нагрузки, а не остаются дефолтными; механика ребаланса — в тринадцатом уроке. Практический замер перед настройкой: возьмите время самой длинной пачки из логов, умножьте на запас и только потом выбирайте SessionTimeout — конфиг, снятый с чужого примера, здесь обходится дороже дефолта.

Ещё две грабли дешевле по ущербу и обнаруживаются диском и латентностью. Symptom первый: диск брокера кончился, запись остановилась. Причина: топик создавался без ConfigEntries, retention остался дефолтным или бесконечным, лог рос без границ — семнадцатый урок разбирает retention.bytes и retention.ms и компакцию как управление этим ростом. Лечение: лимиты на каждый топик при создании, а не после тревоги диска; тут же вспоминаем, что расширять число партиций задним числом опаснее, чем задать лимит заранее. Symptom второй: продюсер выдаёт миллисекунды латентности и перегружает брокера тысячами мелких запросов. Причина: Writer шлёт по одному сообщению на запрос — BatchSize и BatchTimeout остались дефолтными или перекрыты, и десятый урок показывал цену этой разницы: целевой батч — сто сообщений, флаш не реже секунды, плюс BatchBytes как потолок запроса. Лечение: пачка на стороне клиента собирается сама, если дать Writer время и объём, а не рвать WriteMessages на одиночные вызовы там, где можно передать срез. Проверка на стенде: Writer с одним сообщением и Writer со срезом на сотню на одном брокере дают разницу в десятки раз по числу запросов — её достаточно, чтобы почувствовать масштаб.

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