Как начать Zookeeper, а затем Kafka?

Question

Я начинаю с Confluent Kafka, которому требуется запустить Zookeeper (zookeeper-server-start /etc/kafka/zookeeper.properties), а затем Kafka (kafka-server-start /etc/kafka/server.properties). Я пишу сценарий Upstart, который должен запускать как Kafka, так и Zookeeper. Проблема в том, что Kafka должен блокироваться до тех пор, пока Zookeeper не будет готов (потому что это зависит от него), но я не могу найти надежный способ узнать, когда Zookeeper готов. Вот некоторые попытки в псевдо-коде после запуска запуска сервера Zookeeper:

1. Используйте жёстко прописанные Заблокировать

   sleep 5 
   

   не работает надежно на медленных компьютерах и/или ждет дольше, чем это необходимо.

2. Проверить, когда что-то (надеюсь Zookeeper) работает на порту 2181

   wait until $(echo stat | nc localhost ${port}) is not none 
   

   Это не похоже на работу, так как не ждать достаточно долго для Zookeeper принять соединение Кафка.

3. Проверьте журналы

   wait until specific string in zookeeper log is found 
   

   Это схематично и не существует даже строка, которая не может также быть найдена на ошибках тоже (например, «привязка к порту [...]»).

Есть ли надежный способ узнать, когда Zookeeper готов принять соединение Kafka? В противном случае мне придется прибегнуть к комбинации 1 и 2.

Answer 1

сообщения об ошибке, Кафка из вашего комментария, безусловно, актуально:

FATAL [Кафка Сервер 0] Фатальная ошибка при запуске KafkaServer. Подготовьтесь к завершению работы (kafka.server.KafkaServer) java.lang.RuntimeException: брокер уже зарегистрирован на пути/брокерах/идентификаторах/0. Вероятно, это указывает на то, что вы либо настроили брокер, который уже используется, либо вы завершите работу этого брокера и перезапустили его быстрее, чем таймер ожидания zookeeper, поэтому он, похоже, перерегистрируется.

Это указывает на то, что ZooKeeper запущен и работает, и Kafka смог подключиться к нему. Как я и ожидал, техника № 2 была достаточной для проверки того, что ZooKeeper готов принимать соединения.

Вместо этого проблема оказывается на стороне Кафки. Он зарегистрировал ZooKeeper ephemeral node для представления стартового брокера Kafka. Эфемерный узел удаляется автоматически, когда заканчивается сеанс клиента ZooKeeper (например, процесс завершается, поэтому он перестает бить ZooKeeper). Однако это основано на тайм-аутах. Если брокер Kafka перезапустится быстро, то после перезапуска он увидит, что znode, представляющий этот брокер, уже существует. Для начала нового процесса это похоже на то, что уже запущен и зарегистрирован брокер на этом пути. Поскольку у брокеров, как ожидается, будут уникальные идентификаторы, он прерывается.

Ожидание периода времени, прошедшего после истечения срока действия ZooKeeper, является подходящим ответом на эту проблему. При необходимости вы могли бы настроить время истечения сеанса быстрее, как описано в разделе ZooKeeper Administrator's Guide. (См. Обсуждение tickTime, minSessionTimeout и maxSessionTimeout.) Однако истечение срока действия сеанса настройки слишком быстро может привести к тому, что клиенты будут испытывать побочные сеансовые выходы во время обычных операций.

У меня меньше знаний о Кафке, но, возможно, есть что-то, что можно сделать на стороне Кафки. Я знаю, что некоторые инструменты управления, такие как Apache Ambari, предпринимают шаги для гарантирования назначения уникального идентификатора каждому брокеру при предоставлении ресурсов.

Answer 2

Вырожденное CLI введены в версии 3.3.0 делает его очень легко начать все услуги с помощью одной команды:

confluent start 

Более подробная информация в Confluent Platform Quickstart documentation.