Kafka Operations¶

Что важно мониторить¶

Если Kafka уже в проде, то смотреть только на "broker up/down" недостаточно.

Минимум нужно мониторить:

consumer lag
throughput записи и чтения
latency produce/fetch запросов
under-replicated partitions
изменения ISR
disk usage и рост логов
saturation CPU / network / page cache / disk I/O
rebalance frequency у consumer groups

Consumer lag¶

Consumer lag — это насколько consumer group отстает от head log.

Если lag растет, значит:

consumer не успевает обрабатывать;
недостаточно consumers или partition;
downstream тормозит;
poison message заблокировал обработку;
произошел rebalance storm;
topic начал принимать больше трафика, чем раньше.

Важно:

lag сам по себе не всегда авария;
но если он неуклонно растет и группа не догоняет поток, это уже системная проблема.

Under-replicated partitions¶

Если partition under-replicated, значит:

не все expected replicas успевают быть в sync;
часть durability запаса потеряна;
при следующем сбое риски выше.

Это очень важный operational сигнал.

Причины:

broker упал;
follower не успевает по сети или диску;
перегружен leader;
проблемы с storage;
слишком агрессивный throughput без достаточных ресурсов.

ISR shrink / expand¶

Следи не только за фактом "broker жив".

Следи за тем:

часто ли shrink'ится ISR;
насколько долго replica не может вернуться в ISR;
какие topics наиболее проблемные.

Если ISR часто деградирует:

durability ухудшается;
acks=all может начать чаще падать;
риск отказа при следующем сбое растет.

Размер диска и retention¶

Kafka очень любит диск.

Поэтому обязательно контролировать:

объем данных по topic;
скорость роста;
retention;
compaction behavior;
запас места под пики и recovery.

Плохой сценарий:

retention выставили "на глаз";
topic внезапно вырос;
диск забился;
broker начал деградировать или упал.

Как думать про partition count¶

Partition count влияет на:

parallelism;
throughput;
распределение данных по broker'ам;
скорость recovery;
стоимость rebalances;
metadata overhead.

Слишком мало partition¶

не хватает parallelism;
consumer group не масштабируется;
легко получить bottleneck.

Слишком много partition¶

растет overhead;
сложнее управление;
тяжелее rebalance и recovery;
больше operational noise.

Практический принцип:

partition count должен отражать expected throughput и нужный parallelism;
не надо ставить "1000 на всякий случай";
но и "1 partition навсегда" часто быстро становится узким местом.

Hot partition¶

Hot partition возникает, когда:

на одну partition идет disproportionate amount of traffic;
одна key слишком "горячая";
partition strategy неравномерная.

Симптомы:

один consumer перегружен;
lag растет только на части partition;
один broker или один лидер получает больше нагрузки.

Причины:

плохой выбор key;
skewed business distribution;
ручное назначение partition без баланса.

Решение зависит от сценария:

пересмотреть key strategy;
разбить поток по другой сущности;
изменить event design;
иногда сознательно пожертвовать ordering ради распределения нагрузки.

Rebalance storm¶

Если consumer group постоянно ребалансится, это очень больно.

Признаки:

consumers часто теряют assignment;
lag скачет;
throughput падает;
логи забиты join/rejoin событиями.

Частые причины:

слишком долгий processing loop;
неверный max.poll.interval.ms;
нестабильные контейнеры;
frequent deploys;
проблемы сети;
неудачная autoscaling strategy.

Что помогает:

стабилизировать lifetime consumer'ов;
уменьшить время обработки одной пачки;
использовать статическое membership там, где это уместно;
разнести тяжелую обработку и poll loop.

Дубликаты: operational reality¶

Даже если кластер здоров, дубликаты возможны из-за:

retry producer'а;
падения consumer'а после обработки, но до commit;
rebalance;
переигрывания истории;
повторного запуска pipeline.

Поэтому operational truth такая:

продовая Kafka-система должна проектироваться с учетом duplicate-tolerant processing.

Базовые практические настройки для критичных событий¶

Часто разумный baseline такой:

replication.factor = 3
min.insync.replicas = 2
producer: acks=all
producer: idempotence enabled
consumer: manual offset commit
retention осознанно выбрана, а не оставлена случайной

Это не универсальный рецепт, но хороший starting point.

Что проверять, если lag растет¶

Есть ли rebalance storm.
Не уперлись ли consumers в CPU / DB / внешний API.
Не появился ли poison message.
Нет ли hot partition.
Не уменьшился ли ISR и не деградировала ли запись.
Не изменился ли резко входной throughput.
Не слишком ли большие batches/messages.

Что проверять, если producer получает ошибки записи¶

Смотри:

доступность лидеров partition;
размер ISR;
min.insync.replicas;
timeouts и network issues;
не меняется ли metadata слишком часто;
не забит ли диск;
нет ли throttling / quota issues.

Что проверять, если данные "теряются"¶

Сначала надо уточнить, что именно считается потерей:

producer реально не записал?
producer записал, но consumer не дочитал?
consumer закоммитил слишком рано?
retention уже удалил старые записи?
данные лежат, но читаются другой group?
downstream отбросил дубль или ошибку как "неуспех"?

Очень часто проблема не в физической потере сообщений, а в:

неверном offset management;
неверном понимании consumer groups;
слишком маленьком retention;
бизнес-ошибке в обработчике.

Чеклист перед продом¶

Понятно, зачем именно Kafka нужна в этом сценарии.
Понятно, какой key и почему.
Понятно, сколько нужно partition и почему.
Определены replication.factor, min.insync.replicas, acks.
Продуманы retry, idempotence и offset commit strategy.
Продуманы retention и/или compaction.
Есть схема событий и правила versioning.
Есть мониторинг lag, ISR, under-replicated partitions, disk.
Есть план обработки poison messages и DLQ.
Есть понимание replay strategy.

Что запомнить¶

Kafka требует не только coding skills, но и operational discipline.
Самые частые реальные проблемы: lag, rebalance storm, hot partitions, disk pressure, duplicates.
Хороший Kafka-дизайн начинается не с твика конфигов, а с правильных ключей, partitioning, retention и consumer semantics.