Guides
Apache Kafka

Kafka consumer lag: мониторинг и алертинг

Consumer lag в Kafka: как измерить через kafka-consumer-groups.sh, Kafka Exporter для Prometheus, алерты. Что делать ког

#guide#kafka

Consumer lag — это не просто метрика, а главный индикатор здоровья ваших пайплайнов реального времени. Если вы его не отслеживаете, вы летите вслепую, а расплачиваетесь за это данными и SLA. Этот гайд — выжимка опыта, как построить систему мониторинга и реагирования на лаг, чтобы спать спокойно.

Измеряем lag: два практических способа

Для разовых проверок или скриптов нет ничего лучше нативной утилиты. Она даёт моментальный снимок состояния групп.

kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --group my-dataops-group \
  --describe

В выводе смотрите на колонку LAG. Это количество необработанных сообщений на партицию. Ненулевой лаг — норма, растущий или стабильно высокий — проблема.

Для постоянного мониторинга в Prometheus стандартный выбор — Kafka Exporter. Он тянет метрики из кластера и выставляет их в формате, готовом для Grafana. Вот ключевые метрики, которые вам нужны:

kafka_consumer_group_lag_sum
kafka_consumer_group_lag

Первая — суммарный лаг по всем партициям группы, отличный индикатор для общего алерта. Вторая — лаг на партицию, незаменима для детального анализа.

Настраиваем алертинг: не паниковать раньше времени

Главная ошибка — алертить на любой ненулевой лаг. Лаг должен оцениваться в контексте. Используйте в Prometheus Alertmanager правила, которые учитывают динамику и объём.

groups:
- name: kafka_alerts
  rules:
  - alert: KafkaConsumerGroupLagGrowingRapidly
    expr: rate(kafka_consumer_group_latency_sum[5m]) > 10000
    for: 5m
    annotations:
      description: 'Группа {{ $labels.consumergroup }} демонстрирует быстрый рост лага. Текущее суммарное значение: {{ $value }} сообщений.'

Это правило ловит не сам факт наличия лага, а его рост, что гораздо точнее указывает на возникшую проблему в консьюмере.

Что делать, когда лаг растёт: план атаки

  1. Диагностика. Сначала определите, проблема на всех партициях или на отдельных? Равномерный рост по всем партициям указывает на общую недостаточность вычислительной мощности консьюмеров. Рост на одной-двух — на проблему с обработкой сообщений в конкретном потоке (например, упёрлись в исключение или тяжёлое сообщение).

  2. Увеличение параллелизма. Если не хватает мощности, увеличьте количество инстансов консьюмера в группе. Помните золотое правило: параллелизм ограничен количеством партиций в топике. Больше консьюмеров, чем партиций, — бесполезно.

  3. Проверка rebalance. Частые ребалансы — убийца производительности. Убедитесь, что session.timeout.ms и max.poll.interval.ms настроены адекватно вашей логике обработки. Слишком агрессивные таймауты приведут к постоянным перераспределениям партиций.

  4. Оптимизация consumer. Загляните внутрь. Используете ли вы batch-обработку? Настройки fetch.min.bytes и max.poll.records могут серьёзно ускорить потребление. Убедитесь, что логика обработки сообщения не содержит блокирующих вызовов или, что хуже, бесконечных циклов.

Типичные грабли

  • Мониторинг только суммарного лага. Вы можете пропустить “проседающую” партицию, которая тянет всю группу. Всегда смотрите и на метрику kafka_consumer_group_lag.
  • Автоматический scaling по лагу без ограничений. Скейлите, но ставьте hard limit на количество инстансов, равный количеству партиций.
  • Игнорирование max.poll.interval.ms. Если ваша обработка одного батча может занимать длительное время, увеличьте этот параметр. Иначе консьюмер будет исключён из группы, что запустит ребаланс.

Контроль над consumer lag — это контроль над потоком данных. Настройте мониторинг, продумайте алерты и имейте чёткий план действий — тогда вы будете управлять лагом, а не он вами.