Модуль 2. Мониторинг Kafka: lag, ISR, request latency — и что алертить

Цель модуля: видеть Kafka по приборам: четыре группы метрик, которые покрывают 95 % инцидентов; как снять их через kafka-exporter и Prometheus; какой дашборд собрать и какие пять алертов ставить — без «lag > 0» в правилах.

Перед началом: Модуль 1 (модель партиций/групп), курс «Фундамент» (2.6 «что алертить»), Docker. Стенд: make up (кластер ×3) и make up-obs (+ kafka-exporter, Prometheus). Трудоёмкость: ~8–10 ч (теория 4 ч · практика 4 ч · квиз 1 ч).

📖 2.1. Четыре группы метрик

1. Консьюмеры (lag). Отставание группы по партиции — разница между концом лога и закоммиченным офсетом:

bash
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --describe --group billing
# CURRENT-OFFSET  LOG-END-OFFSET  LAG

Lag — главный симптом очереди, но читается с оговорками (§2.3).

2. Репликация (ISR). In-Sync Replicas — реплики, не отставшие от лидера партиции. Здоровье кластера видно по трём числам:

• under-replicated partitions (URP) — партиций с отставшими репликами; в здоровом кластере — 0;
• offline partitions — партиций без лидера: кластер деградировал, запись/чтение в эти партиции невозможны;
• IsrShrinksPerSec / IsrExpandsPerSec — «дыхание» ISR. Разовое сжатие при инциденте — норма; постоянное ритмичное — деградация сети/диска.

3. Производительность брокеров. Request latency (Produce/Fetch, смотреть p99, не среднее), request handler idle % (запас потоков), bytes in/out. Это метрики «брокер чувствует себя хорошо».

4. Хранилище. Диск по брокерам (retention умножается на партиции: кончается место — брокер падает или режет сегменты), размер активного сегмента, log.dirs доступность.

📖 2.2. JMX и kafka-exporter: как метрики попадают в Prometheus

Kafka отдаёт метрики через JMX (MBeans). В KRaft-мире их можно снять kafka-run-class.sh kafka.tools.JmxTool, но для Prometheus ставят экспортер — danielqsj/kafka-exporter: подключается к кластеру как клиент и публикует то, что нужно очереди:

Broker-внутренние метрики (request latency, handler idle, диск) экспортер не даёт — их берут JVM-агентом (jmx_exporter javaagent на брокерах) или псевдо-метриками хоста. На стенде курса стартуем с kafka-exporter (очередные метрики), broker-JMX оставим как «следующий уровень».

📖 2.3. Lag: главная метрика и её тёмная сторона

Три ловушки, из-за которых «lag растёт» пишут в алерты зря:

1. Lag > 0 — норма. Пока консьюмер читает с disk-ретеншеном, он всегда «чуть позади». Плох не lag, а растущий lag при работающих консьюмерах — смотрите производную: deriv(kafka_consumergroup_lag[10m]) > 0;
2. Lag после рестарта группы скакнул до размера лога? Это офсеты не закоммичены (упали до commit) или auto.offset.reset=earliest у нового consumer group id. Лечение — в Модуле 3 (инцидент «rebalance storm»);
3. Lag по одной партиции при нулях в остальных — горячая партиция: кривой ключ партиционирования (один жирный заказ = одна партиция). Лечится ключом, а не мощностью консьюмеров.

Полезная производная от lag — время догона: lag делить на средний rate обработки группы. «Lag 50 000» при 5 000 msg/s — это 10 секунд; при 50 msg/s — это 16 минут. Одно число без rate не значит ничего.

📖 2.4. Дашборд: восемь панелей

Порядок панелей = порядок взгляда при инциденте (как в курсе Redis):

1. Lag по группам (стек, топ-5): суммарный lag каждой группы;
2. Lag по партициям (топ-10): найти горячую партицию;
3. URP / offline partitions: здоровье кластера одним взглядом;
4. ISR shrinks/expands rate: «дыхание» репликации;
5. Messages in/out по брокерам (throughput);
6. Консьюмеры группы: количество живых членов (members) — упали воркеры?
7. Брокеры: kafka_brokers — размер кластера (упал ли узел);
8. Диск по брокерам (если есть node-exporter/JMX) и время догона (кастомная запись из практики).

Панели 1–2 — «наша очередь», 3–8 — «наш кластер». При «очередь встала» сначала 1–2, потом 7 (кластер жив?), и только затем остальное.

📖 2.5. Пять алертов и два антипримера

Антипримеры: «lag > 0» (норма, см. §2.3) и «request latency p99 > 100 мс» без привязки к базе (p99 зависит от батчинга и linger.ms — 100 мс при linger=20 и компрессии может быть отличным числом).

💻 Практика

1. Кластер + наблюдаемость: make up-obs — KRaft-кластер из трёх брокеров, kafka-exporter (:9301), Prometheus (:9090). Проверьте http://localhost:9090/targets.
2. Пропустите трафик: продюсер 1 000 msg/s с ключом order_id; группа из двух консьюмеров. Найдите на дашборде: lag ≈ 0, members = 2.
3. Отстающий консьюмер: остановите одного консьюмера и добавьте обработчику паузу 100 мс — наблюдайте рост lag по всем партициям этой группы, производную из §2.5.
4. Горячая партиция: смените ключ продюсера на константу — весь трафик в одну партицию; lag по одной партиции растёт, остальные — нули.
5. Убейте брокера: make kill-broker — наблюдайте: URP подскочил и вернулся в 0 (ISR-дыхание), kafka_brokers упал до 2, офсеты группы живы, запись продолжается (RF=3, min.insync=2). Поднять: make up-broker.
6. Алерты: соберите пятёрку из §2.5 в config/alerts.yml стенда — на эталонном кластере с работающим шагом 4 дёрните каждый.

Артефакт: config/alerts.yml + скриншот дашборда с двумя экспериментами (отстающий консьюмер, kill-broker).

🧩 Quiz "Проверь себя"

✅ Итоги модуля

🔗 Мостик к Модулю 3

Приборы стоят. Дальше — читать их в момент боли: инциденты Kafka — rebalance storm, лаг без деградации продюсера, ISR shrink и unclean leader election, disk full и NOT_ENOUGH_REPLICAS: каждый — симптом → метрика → причина → лечение, и все воспроизводятся на трёхузловом стенде (make kill-broker теперь ваш нож).