Таксономия JMX-метрик Kafka

Прежде чем настраивать Grafana-дашборды и писать Prometheus-правила, необходимо знать, что именно измерять. Kafka экспортирует сотни JMX-метрик. Большинство из них вы никогда не будете смотреть в боевой обстановке. Но десяток критически важных метрик должен быть перед глазами каждые 24 часа.

Этот урок — систематизированный каталог метрик по категориям: брокер, реквесты, продюсер, консьюмер, KRaft-контроллер. Для каждой метрики: точное имя MBean, нормальное значение, порог алерта, причина аномалии.

JMX в Kafka: фундамент экспорта метрик

Kafka написана на JVM и использует Java Management Extensions (JMX) — стандартный механизм инструментирования JVM-приложений. Каждая метрика представлена как MBean (Managed Bean) с уникальным именем в формате:

domain:type=TypeValue,name=MetricName[,additionalKey=additionalValue]

Примеры:

• kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions
• kafka.network:type=RequestMetrics,name=TotalTimeMs,request=Produce
• kafka.producer:type=producer-metrics,client-id=my-producer,name=record-send-rate

Доступ к JMX:

# Запуск Kafka с JMX-портом
export JMX_PORT=9999
bin/kafka-server-start.sh config/server.properties

# Или через KAFKA_JMX_OPTS
export KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote \
  -Dcom.sun.management.jmxremote.port=9999 \
  -Dcom.sun.management.jmxremote.authenticate=false \
  -Dcom.sun.management.jmxremote.ssl=false"

Kafka 4.0 и KRaft: В Kafka 4.0 ZooKeeper полностью удалён. Это непосредственно влияет на метрики: все SessionExpireListener и ZooKeeper-era метрики контроллера удалены, вместо них появились новые KRaft-специфичные метрики. Если вы мигрируете мониторинг с Kafka 3.x на 4.0 — читайте раздел о запрещённых метриках в конце урока.

Broker-level метрики: мониторить всегда

Это метрики, которые должны быть на вашем главном дашборде. Отклонение любой из них от нормы — потенциальный инцидент.

Детальный справочник критических метрик брокера:

kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions

Количество партиций, где ISR (In-Sync Replicas) меньше replication.factor. Это не то же самое, что UnderMinIsrPartitionCount. Партиция может быть under-replicated (ISR=2 при RF=3), но всё ещё принимать записи (если min.insync.replicas=2). Норма: 0. Если значение больше 0 в течение более 5 минут — это инцидент. Допустима ненулевая значение во время перезапуска брокера (rolling restart): несколько минут, пока фолловер догоняет лидера.

kafka.server:type=ReplicaManager,name=UnderMinIsrPartitionCount

Партиции, где ISR упал ниже min.insync.replicas. Для этих партиций produce с acks=all будет отклонён: NotEnoughReplicasException. Норма: строго 0. Любое значение больше 0 — немедленный алерт, бизнес под угрозой.

kafka.controller:type=KafkaController,name=ActiveControllerCount

В KRaft-кластере ровно один брокер является активным контроллером (Raft-лидером). Значение должно быть 1 на каждом брокере (каждый знает, кто контроллер). Alert при != 1.

kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent

Доля времени, когда I/O-потоки брокера не заняты обработкой запросов. Значение 1.0 = все потоки простаивают (нет нагрузки). Значение 0.0 = все потоки заняты 100% времени (перегрузка). Норма: выше 0.30. При значении ниже 0.30 больше 10 минут: увеличьте num.io.threads или добавьте брокеры.

Request-level метрики: диагностика задержек

Когда latency растёт, эти метрики показывают, на каком этапе обработки запроса возникает задержка.

Ключевые request-level метрики:

kafka.network:type=RequestMetrics,name=TotalTimeMs,request=Produce

Полная задержка produce-запроса. MBean атрибуты: Mean, 50thPercentile, 95thPercentile, 99thPercentile, 999thPercentile. В production отслеживайте p99 и p999. Норма p99 при acks=all: меньше 100ms. При acks=1: меньше 20ms. Alert при p99 больше 500ms — disk bottleneck или ISR-проблема.

kafka.network:type=RequestMetrics,name=TotalTimeMs,request=FetchConsumer

Задержка ответа на fetch-запрос потребителя. Включает fetch.min.bytes waiting time (брокер ждёт накопления данных). При нормальной нагрузке и настроенных fetch.min.bytes/fetch.max.wait.ms — ожидаемо высокое значение p50 (потребитель ждёт данных). Проблемой является рост p999.

kafka.network:type=RequestMetrics,name=TotalTimeMs,request=FetchFollower

Задержка fetch-запросов от фолловеров. Если растёт — фолловеры не успевают реплицировать. Следствие: ISR сжимается, UnderReplicatedPartitions растёт.

kafka.network:type=RequestMetrics,name=RequestsPerSec,request=Produce

Количество produce-запросов в секунду. Отличается от record-send-rate (одна запись) тем, что один запрос может содержать batch из тысяч записей. Позволяет оценить накладные расходы на запросы.

Producer-side метрики: диагностика на стороне клиента

Producer-метрики привязаны к client-id. В JMX-нотации client-id=* означает, что нужно подставить реальный client.id вашего продюсера.

Полный список producer JMX метрик:

bufferpool-wait-ratio — часто упускаемая метрика. Значение больше 0.01 означает: продюсер блокируется ожидая свободного места в buffer.memory. Решение: увеличить buffer.memory или снизить нагрузку.

Consumer-side метрики: лаг как главный индикатор

Главная метрика консьюмера — лаг. Всё остальное вторично.

Детализированный лаг per partition: Помимо records-lag-max (агрегат), можно смотреть лаг по конкретной партиции:

kafka.consumer:type=consumer-fetch-manager-metrics,
  client-id={id},topic={topic},partition={N},name=records-lag

Это позволяет обнаружить, что проблема только с одной партицией (например, hot partition или проблема с конкретным брокером).

KRaft Controller метрики (Kafka 4.0 specific)

В Kafka 4.0 контроллер работает на основе Raft-протокола. Часть метрик появилась заново или изменила смысл.

Дополнительные KRaft-метрики:

• kafka.controller:type=KafkaController,name=OfflinePartitionsCount — партиции без лидера. Норма: 0. Если больше 0 — данные недоступны для чтения и записи.
• kafka.controller:type=KafkaController,name=PreferredReplicaImbalanceCount — партиции, где текущий лидер не является предпочтительным (preferred leader). Ненулевое значение допустимо после rolling restart, но должно снижаться.

Метрики, которых больше нет в Kafka 4.0

При миграции мониторинга с Kafka 3.x на 4.0 следующие метрики не будут эмитировать данные:

Если ваш старый Prometheus/Grafana стек содержит alerts на эти метрики — они будут вечно отсутствовать (no data), что может триггерить “no data” алерты. Удалите или обновите такие алерты при переходе на Kafka 4.0.

Сводная таблица топ-15 метрик