Итоги модуля: Production Operations
Модуль 10 закрывает разрыв между “знаю Kafka API” и “умею эксплуатировать Kafka в production”. Здесь собраны все ключевые числа, пороги и операционные процедуры.
Production ops checklist
Каждый этап ссылается на урок модуля
Plan (capacity)
Урок 04: Capacity Planning. Диск (daily_GB = rate × size × 86400 × RF). Партиции (max throughput-based, consumer-based). Сеть (inbound + replication + consumer). Память (6GB heap + page cache). +30-40% headroom.Monitor (JMX/Prometheus)
Урок 01-02: JMX Metrics + Monitoring Stack. JMX Exporter + Prometheus + Grafana. Алерты на URP, RequestHandlerAvgIdlePercent, consumer lag. Два экспортера: JMX для broker internals, kafka-exporter для consumer group lag.Tune (performance)
Урок 03: Performance Tuning. Throughput: batch.size=1MB, linger.ms=50, lz4. Latency: batch.size=16KB, linger.ms=0, acks=1. Consumer: fetch.min.bytes=1MB, max.poll.records=1000.Scale (reassign)
Урок 05: kafka-reassign-partitions. --generate + --execute + --verify. ВСЕГДА с --throttle (50 MB/s). После завершения: удалить throttle, запустить preferred leader election.Repeat
Кластер сбалансирован, мониторинг работает. Вернуться к Plan: пересчитать ёмкость по мере роста нагрузки. Цикл повторяется с каждым значимым изменением нагрузки.Monitoring checklist:
- JMX Exporter (port 9404) настроен на всех брокерах
- kafka-exporter настроен для consumer group lag
- Prometheus scrape: 15s для JMX, 30s для kafka-exporter
- Grafana дашборд с панелями: Broker Health, Throughput, Latency, Consumer Lag
- Алерты настроены (минимум): URP > 0 на 5 мин, RequestHandlerAvgIdlePercent < 0.3, consumer lag > 10000
Performance checklist:
- Throughput producer: batch.size=1MB, linger.ms=50, compression=lz4, buffer.memory=64MB
- Latency producer: batch.size=16KB, linger.ms=0, compression=none, acks=1
- Consumer: fetch.min.bytes=1MB, max.poll.records=1000
- Broker: НЕ настраивать log.flush.interval.messages/ms
Capacity checklist:
- Формулы посчитаны для текущей нагрузки
- +30-40% headroom на все ресурсы
- Partition count = max(throughput-based, consumer-based) × 2, кратно числу брокеров
- NIC утилизация не превышает 70%
Operations checklist:
- kafka-reassign-partitions процедура задокументирована
- Throttle значение рассчитано для кластера
- Runbook для добавления/удаления брокера готов
Ключевые числа: сводная таблица
ПараметрПараметр или метрика
Рекомендованное значениеРекомендованное значение или нормальный диапазон
Alert-порогКогда требуется действие
UnderReplicatedPartitionsКритическая метрика брокера. 0 в норме.
0Строго 0 в production. Допустим временный рост при rolling restart.
больше 0 на 5+ минНемедленная диагностика: проверить брокеры, диск, сеть.
RequestHandlerAvgIdlePercentЗагрузка I/O-потоков брокера.
больше 0.30 (30% простоя)30% idle = достаточный запас. Меньше 30% = брокер приближается к пределу.
меньше 0.30 на 10+ минУвеличить num.io.threads или добавить брокеры.
ActiveControllerCountKRaft контроллер: должен быть ровно 1.
1Ровно один активный KRaft-контроллер.
не равно 10 = нет контроллера. Больше 1 = split-brain. Оба критичны.
Produce TotalTimeMs p99Задержка produce запроса на 99-м перцентиле.
меньше 100ms (acks=all)При acks=1: менее 20ms. При acks=all: менее 100ms.
больше 500msDisk bottleneck или ISR-ожидание. Диагностика: LocalTimeMs и RemoteTimeMs.
records-lag-maxМаксимальный лаг консьюмера.
меньше 100Нормальный лаг при стабильной нагрузке.
больше 1000 / больше 10000Warning: больше 1000. Critical: больше 10000.
batch.size (throughput)Размер batch для throughput-оптимизации.
1048576 (1 MB)1 MB: baseline для throughput producer. Увеличивает эффективность batch-ing.
Не применимоЭто конфигурация, не метрика. Сравнивайте с batch-size-avg JMX.
linger.ms (throughput)Время ожидания для заполнения batch.
50ms50ms: baseline для throughput producer. Trade-off: +50ms latency.
Не применимоКонфигурация. Смотреть record-queue-time-avg JMX.
compression.typeАлгоритм сжатия для throughput.
lz4lz4: оптимальный баланс ratio/speed. Для bandwidth-limited: zstd.
Избегать gzipgzip слишком медленный для высоконагруженных систем.
fetch.min.bytesМинимальный объём данных перед fetch-ответом.
1048576 (1 MB)1 MB: снижает число fetch-запросов при высокой нагрузке. Default 1 byte = неэффективно.
Не применимоКонфигурация. Влияет на fetch-rate JMX метрику.
JVM HeapРазмер heap Kafka-брокера.
6 GB (фиксированный)-Xms6g -Xmx6g. Не увеличивать. Больше heap = GC паузы.
больше 8 GBБолее 8 GB heap -> GC паузы -> spike latency. Не рекомендуется.
NIC утилизацияЗагрузка сетевой карты брокера.
меньше 70%70% -- предел для sustained трафика. Оставшиеся 30% = burst headroom + reassignment.
больше 70% sustainedДобавить брокеры или перейти на 10 Gbps NIC.
Headroom (disk/network)Запас ёмкости относительно текущей нагрузки.
30-40%30-40% запас: достаточно для burst и partition reassignment.
меньше 20%При запасе менее 20% -- срочно расширять кластер.
Throttle (reassignment)Скорость реплицирования при partition reassignment.
50 MB/s (52428800)Baseline для 1 Gbps NIC с умеренным трафиком. Корректируйте по доступной пропускной способности.
0 (без throttle)Никогда не выполнять reassignment без throttle в production.
Типичные ошибки production ops
1. Reassignment без throttleПоследствие: весь сетевой и дисковый I/O потребляется репликацией. Producers получают TimeoutException. Consumers накапливают lag. Правило: ВСЕГДА --throttle при --execute.
2. Чрезмерное количество партицийПоследствие: каждая партиция = open file handles, индексные файлы, память для ISR tracking. При 100,000 партициях на брокере: деградация контроллера, slow leader elections. Правило: начинать с минимального расчётного числа.
3. log.flush.interval.messages в productionПоследствие: принудительный fsync после каждого N сообщений убивает throughput (в 10-100x). Kafka специально использует OS page cache и периодический fsync. Durability = replication (acks=all), не fsync.
4. JVM Heap больше 8 GBПоследствие: GC паузы при Full GC на большом heap -- stop-the-world на несколько секунд. Kafka брокер не реагирует на запросы во время GC паузы. Правило: -Xms6g -Xmx6g, без вариантов.
Связь с предыдущими модулями
Production ops применяет знания из всего курса:
| Тема | Модуль | Применение в Production Ops |
|---|---|---|
| ISR, репликация | Модуль 01 | UnderReplicatedPartitions диагностика |
| Producer API | Модуль 02 | batch.size, linger.ms, acks config |
| Consumer API | Модуль 03 | fetch.min.bytes, lag monitoring |
| Log segments | Модуль 04 | Disk sizing, page cache |
| Квоты | Модуль 09 | Встроены в production ops checklist |