Comment démarrer Zookeeper puis Kafka?

Question

Je commence avec Confluent Kafka qui nécessite de lancer Zookeeper (zookeeper-server-start /etc/kafka/zookeeper.properties) puis Kafka (kafka-server-start /etc/kafka/server.properties). J'écris un script Upstart qui devrait exécuter à la fois Kafka et Zookeeper. Le problème est que Kafka devrait bloquer jusqu'à ce que Zookeeper soit prêt (parce que cela dépend de lui) mais je ne peux pas trouver un moyen fiable de savoir quand Zookeeper est prêt. Voici quelques tentatives de pseudo-code après l'exécution du démarrage du serveur Zookeeper:

1. Utilisez un bloc hardcoded

   sleep 5 
   

   ne fonctionne pas correctement sur les ordinateurs plus lents et/ou attend plus longtemps que nécessaire.

2. Vérifiez quand quelque chose semble (je l'espère Zookeeper) est en cours d'exécution sur le port 2181

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

   Cela n'a pas travailler comme il n'attend pas assez longtemps pour que Zookeeper d'accepter une connexion Kafka.

3. Vérifiez les journaux

   wait until specific string in zookeeper log is found 
   

   C'est peu précis et il n'y a même pas une chaîne qui ne peut être trouvée aussi en cas d'erreur trop (par exemple « connecte au port [...] »).

Existe-t-il un moyen fiable de savoir quand Zookeeper est prêt à accepter une connexion Kafka? Sinon, je vais devoir recourir à une combinaison de 1 et 2.

Answer 1

Le message d'erreur Kafka de votre commentaire est certainement pertinent:

FATAL [Kafka serveur 0], Erreur fatale lors du démarrage KafkaServer. Préparez-vous à arrêter (kafka.server.KafkaServer) java.lang.RuntimeException: Un courtier est déjà enregistré sur le chemin/brokers/ids/0. Cela indique probablement que vous avez configuré un courtier qui est déjà utilisé, ou bien vous avez arrêté ce courtier et l'avez redémarré plus rapidement que le délai d'expiration du zookeeper, de sorte qu'il semble se réenregistrer.

Ceci indique que ZooKeeper est opérationnel et que Kafka a pu s'y connecter. Comme je m'y attendais, la technique n ° 2 était suffisante pour vérifier que ZooKeeper est prêt à accepter les connexions. Au lieu de cela, le problème semble être du côté de Kafka. Il a enregistré un ZooKeeper ephemeral node pour représenter le courtier Kafka de départ. Un noeud éphémère est supprimé automatiquement lorsque la session ZooKeeper du client expire (par exemple, le processus se termine de sorte qu'il cesse de battre le cœur de ZooKeeper). Cependant, cela est basé sur les délais d'attente. Si le courtier Kafka redémarre rapidement, alors après le redémarrage, il voit qu'un znode représentant ce courtier existe déjà. Au début du nouveau processus, il semble qu'il y ait déjà un courtier démarré et enregistré sur ce chemin. Puisque les courtiers sont censés avoir des identifiants uniques, ils avortent.

Attendre une période de temps après l'expiration de la session ZooKeeper est une réponse appropriée à ce problème. Si nécessaire, vous pouvez potentialiser l'expiration de la session pour qu'elle se produise plus rapidement, comme indiqué dans le document ZooKeeper Administrator's Guide. (Voir la discussion de tickTime, minSessionTimeout et maxSessionTimeout.Toutefois, si l'expiration de la session est trop rapide, les clients risquent de subir des expirations de session erronées pendant les opérations normales. J'ai moins de connaissances sur Kafka, mais il y a peut-être aussi quelque chose qui peut être fait du côté de Kafka. Je sais que certains outils de gestion tels que Apache Ambari prennent des mesures pour garantir l'attribution d'un identifiant unique à chaque courtier lors du provisionnement.

Answer 2

Le Confluent CLI introduit dans la version 3.3.0, il est vraiment facile de démarrer tous les services avec une seule commande:

confluent start 

Plus de détails dans le Confluent Platform Quickstart documentation.