Лучшие практики мониторинга здоровья Kafka с помощью встроенных команд

Используйте CLI-команды Kafka для проверки репликации топиков, отставания потребителей, статуса API брокеров и общего состояния кластера во время инцидентов.

Лучшие практики мониторинга здоровья Kafka с помощью встроенных команд

Встроенные команды Kafka — это самый быстрый способ ответить на основные вопросы при инцидентах: есть ли лидеры у партиций, синхронизированы ли реплики, не отстают ли потребители? Они не заменяют Prometheus, JMX или управляемую платформу мониторинга, но отлично подходят для быстрых проверок с бастион-хоста или административного контейнера.

Примеры ниже используют --bootstrap-server, который является текущим клиентским путём для команд администрирования Kafka.

Настройка чистой среды команд

Храните список брокеров в переменной, чтобы каждая команда была повторяемой:

export KAFKA_HOME=/opt/kafka
export BOOTSTRAP_SERVER="kafka1:9092,kafka2:9092,kafka3:9092"
cd "$KAFKA_HOME/bin"

Если ваш кластер использует TLS или SASL, поместите настройки клиента в файл свойств и передайте его с помощью --command-config:

./kafka-topics.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --command-config /etc/kafka/admin-client.properties \
  --list

Проверка здоровья топиков и партиций

Начните с kafka-topics.sh --describe. У здорового топика должен быть лидер для каждой партиции и список синхронизированных реплик (ISR), соответствующий ожидаемому фактору репликации.

./kafka-topics.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --describe \
  --topic orders

Обратите внимание на эти поля:

  • Leader: не должно быть none.
  • Replicas: назначенные брокеры для партиции.
  • Isr: реплики, которые в данный момент синхронизированы с лидером.

Если в Replicas три брокера, а в Isr только один, топик недореплицирован. Обычно это указывает на отказ брокера, проблемы с диском, сетевые неполадки или реплику, которая не успевает.

Быстрый поиск недореплицированных партиций

Используйте встроенный фильтр, когда нужна быстрая проверка всего кластера:

./kafka-topics.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --describe \
  --under-replicated-partitions

Отсутствие вывода — хорошая новость. Любой вывод заслуживает расследования, особенно для топиков с настроенным min.insync.replicas для более высокой надёжности.

Мониторинг отставания потребителей

Отставание потребителей показывает, успевает ли группа потребителей за произведёнными записями.

./kafka-consumer-groups.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --describe \
  --group payments-worker

Важные столбцы:

  • CURRENT-OFFSET: где группа зафиксировала прогресс.
  • LOG-END-OFFSET: последний смещение в партиции.
  • LAG: разница между ними.
  • CONSUMER-ID, HOST и CLIENT-ID: какой потребитель владеет партицией.

Короткие всплески могут быть нормальными во время развёртываний или всплесков трафика. Устойчивое отставание означает, что группе требуется внимание: медленная обработка, слишком мало потребителей, дисбаланс партиций, задержки зависимых downstream-систем или задержки на стороне брокера при выборке.

Список активных групп потребителей

Если вы не знаете имя группы, сначала выведите список групп:

./kafka-consumer-groups.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --list

Затем проверьте группу, соответствующую затронутому приложению.

Проверка доступности API брокера

kafka-broker-api-versions.sh — простой способ убедиться, что ваш клиент может достичь брокеров и выполнить рукопожатие метаданных/API.

./kafka-broker-api-versions.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER"

Если это не удаётся, проверьте DNS, группы безопасности или брандмауэры, настройки TLS/SASL и доступность объявленных адресов слушателей из места выполнения команды.

Использование CLI-проверок во время инцидентов

Практический поток устранения неполадок выглядит так:

  1. Запустите kafka-broker-api-versions.sh, чтобы подтвердить связь.
  2. Запустите kafka-topics.sh --describe --under-replicated-partitions, чтобы проверить здоровье репликации.
  3. Опишите затронутый топик и проверьте лидеров и ISR.
  4. Опишите затронутую группу потребителей и проверьте отставание по партициям.
  5. Сравните медленные партиции с журналами брокера, диска и приложения.

Вывод

Встроенные команды Kafka дают надёжный первый взгляд на здоровье кластера. Держите конфигурации административного клиента готовыми, используйте --bootstrap-server и сосредоточьтесь на лидерах, ISR, недореплицированных партициях и отставании потребителей. Как только CLI покажет, где находится проблема, более глубокие метрики брокера и журналы будет гораздо легче интерпретировать.