Leader indisponible Kafka dans Console Producer

J’essaie d’utiliser Kafka. Toutes les configurations sont effectuées correctement mais lorsque j’essaie de produire un message à partir de la console, je continue à recevoir des erreurs

WARN Error while fetching metadata with correlation id 39 : {4-3-16-topic1=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient) 

version kafka: 2.11-0.9.0.0

Quelqu’un peut-il s’il vous plaît aider car je suis incapable de trouver une solution n’importe où?

    Cela peut être lié au paramètre advertised.host.name dans votre server.properties .

    Ce qui pourrait arriver, c’est que votre producteur essaie de savoir qui est le leader pour une partition donnée, de déterminer son advertised.host.name et advertised.port et d’essayer de se connecter. Si ces parameters ne sont pas correctement configurés, il peut alors être considéré que le leader n’est pas disponible.

    J’ai essayé toutes les recommandations listées ici. Ce qui a fonctionné pour moi était d’aller sur server.properties et d’append:

     port = 9092 advertised.host.name = localhost 

    Laissez les listeners et les advertised_listeners commentés.

    Kafka fonctionnait comme un conteneur Docker et des messages similaires inondaient le journal.
    Et KAFKA_ADVERTISED_HOST_NAME été défini sur ‘kafka’.

    Dans mon cas, la raison de l’erreur était l’absence de l’enregistrement /etc/hosts pour «kafka» dans le conteneur «kafka» lui-même.
    Donc, par exemple, l’exécution de ping kafka dans le conteneur ‘kafka’ échouerait avec ping: bad address 'kafka'

    En termes de Docker, ce problème est résolu en spécifiant le hostname d’ hostname du conteneur.

    Options pour y parvenir:

    • docker run --hostname ...
    • docker run -it --add-host ...
    • hostname dans docker-compose
    • hostname dans la définition de tâche AWS EC2

    Ce qui m’a résolu c’est de mettre les auditeurs comme ça:

     advertised.listeners = PLAINTEXT://my.public.ip:9092 listeners = PLAINTEXT://0.0.0.0:9092 

    Cela permet au courtier KAFKA d’écouter toutes les interfaces.

    J’utilise kafka_2.12-0.10.2.1:

    vi config / server.properties

    append la ligne ci-dessous:

     listeners=PLAINTEXT://localhost:9092 
    • Pas besoin de changer les advertised.listeners car il récupère la valeur de la propriété std listener.

    Nom d’hôte et port que le courtier annoncera aux producteurs et aux consommateurs. Si non défini,

    • il utilise la valeur pour “listeners” s’il est configuré

    . Sinon, il utilisera la valeur renvoyée par java.net.InetAddress.getCanonicalHostName ().

    arrêtez le courtier Kafka:

     bin/kafka-server-stop.sh 

    redémarrer le courtier:

     bin/kafka-server-start.sh -daemon config/server.properties 

    et maintenant vous ne devriez plus voir aucun problème.

    Nous avons tendance à recevoir ce message lorsque nous essayons de s’abonner à un sujet qui n’a pas encore été créé. Nous nous appuyons généralement sur des sujets à créer a priori dans nos environnements déployés, mais nous avons des tests de composants qui s’exécutent sur une instance de kafka dockerisée, qui démarre à chaque fois.

    Dans ce cas, nous utilisons AdminUtils dans notre configuration de test pour vérifier si le sujet existe et le créer sinon. Voir cet autre débordement de stack pour en savoir plus sur la configuration d’AdminUtils.

    Une autre possibilité pour cet avertissement (en 0.10.2.1) est que vous essayez d’interroger un sujet qui vient d’être créé et que le leader de cette partition-sujet n’est pas encore disponible, vous êtes en train d’être élu.

    Attendre une seconde entre la création du sujet et l’interrogation est une solution de contournement.

    Pour ceux qui essaient de lancer kafka sur kubernetes et de rencontrer cette erreur, voici ce qui a finalement été résolu:

    Vous devez soit:

    1. Ajoutez le hostname d’ hostname à la spécification de pod, de cette façon kafka peut se trouver.

    ou

    1. Si vous utilisez hostPort , vous avez besoin de hostNetwork: true et dnsPolicy: ClusterFirstWithHostNet

    La raison en est que Kafka doit se parler et décide d’utiliser le listener / hostname annoncé pour se trouver, plutôt que d’utiliser localhost. Même si vous avez un service qui pointe le nom d’hôte annoncé sur le pod, il n’est pas visible depuis le pod. Je ne sais pas vraiment pourquoi c’est le cas, mais au moins il y a une solution de rechange.

     apiVersion: extensions/v1beta1 kind: Deployment metadata: name: zookeeper-cluster1 namespace: default labels: app: zookeeper-cluster1 spec: replicas: 1 selector: matchLabels: app: zookeeper-cluster1 template: metadata: labels: name: zookeeper-cluster1 app: zookeeper-cluster1 spec: hostname: zookeeper-cluster1 containers: - name: zookeeper-cluster1 image: wurstmeister/zookeeper:latest imagePullPolicy: IfNotPresent ports: - containerPort: 2181 - containerPort: 2888 - containerPort: 3888 --- apiVersion: v1 kind: Service metadata: name: zookeeper-cluster1 namespace: default labels: app: zookeeper-cluster1 spec: type: NodePort selector: app: zookeeper-cluster1 ports: - name: zookeeper-cluster1 protocol: TCP port: 2181 targetPort: 2181 - name: zookeeper-follower-cluster1 protocol: TCP port: 2888 targetPort: 2888 - name: zookeeper-leader-cluster1 protocol: TCP port: 3888 targetPort: 3888 --- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: kafka-cluster namespace: default labels: app: kafka-cluster spec: replicas: 1 selector: matchLabels: app: kafka-cluster template: metadata: labels: name: kafka-cluster app: kafka-cluster spec: hostname: kafka-cluster containers: - name: kafka-cluster image: wurstmeister/kafka:latest imagePullPolicy: IfNotPresent env: - name: KAFKA_ADVERTISED_LISTENERS value: PLAINTEXT://kafka-cluster:9092 - name: KAFKA_ZOOKEEPER_CONNECT value: zookeeper-cluster1:2181 ports: - containerPort: 9092 --- apiVersion: v1 kind: Service metadata: name: kafka-cluster namespace: default labels: app: kafka-cluster spec: type: NodePort selector: app: kafka-cluster ports: - name: kafka-cluster protocol: TCP port: 9092 targetPort: 9092 

    Ajout de ceci car cela peut aider les autres. Un problème commun peut être une mauvaise configuration de advertised.host.name . Avec Docker utilisant docker-compose, le nom du service dans KAFKA_ADVERTISED_HOST_NAME ne fonctionnera pas, sauf si vous définissez également le nom d’hôte. Exemple avec docker-compose.yml :

      kafka: image: wurstmeister/kafka ports: - "9092:9092" hostname: kafka environment: KAFKA_ADVERTISED_HOST_NAME: kafka KAFKA_CREATE_TOPICS: "test:1:1" KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181 volumes: - /var/run/docker.sock:/var/run/docker.sock 

    Le ci-dessus sans hostname: kafka peut émettre un LEADER_NOT_AVAILABLE lorsque vous essayez de vous connecter. Vous pouvez trouver un exemple d’une configuration de docker-compose fonctionnelle ici

    J’utilise docker-compose pour construire le conteneur Kafka en utilisant l’image wurstmeister/kafka . L’ KAFKA_ADVERTISED_PORT: 9092 propriété KAFKA_ADVERTISED_PORT: 9092 à mon fichier docker-compose résolu cette erreur pour moi.

    Étant donné que je voulais que mon courtier kafka se connecte avec les producteurs et les consommateurs distants, je ne veux donc pas que advertised.listener soit commenté. Dans mon cas, (en exécutant kafka sur kubernetes), j’ai découvert que mon kafka pod n’avait pas d’IP de cluster. En supprimant la ligne clusterIP: None de services.yml, le kubernetes assigne un pod interne-ip à kafka. Cela a résolu mon problème de LEADER_NOT_AVAILABLE et aussi la connexion à distance des producteurs / consommateurs de kafka.

    J’ai connu le même problème aujourd’hui. Ce que j’ai fait pour contourner cette erreur est de faire une modification subtile dans le fichier /etc/hosts :

    Changez la ligne 127.0.0.1 localhost localhost.localdomain à 10.0.11.12 localhost localhost.localdomain

    (Supposons que 10.0.11.12 est une des adresses IP de votre hôte sur lesquelles le serveur Kafka écoute)

    Pour tous ceux qui ont du mal à configurer Kafka ssl et à voir cette erreur LEADER_NOT_AVAILABLE. Le fichier de clés et le fichier de clés certifiées sont l’une des raisons qui peuvent être à l’origine. Dans le fichier de clés, vous devez avoir une clé privée du serveur + un certificate de serveur signé. Dans le fichier de clés certifiées du client, vous devez disposer d’un certificate CA intermédiaire pour que le client puisse authentifier le serveur kafka. Si vous utilisez ssl pour la communication inter-courtier, vous devez également définir ce fichier de confiance dans le fichier server.properties des courtiers pour qu’ils puissent s’authentifier.

    Ce dernier morceau que je manquais à tort m’a causé beaucoup d’heures douloureuses à découvrir ce que cette erreur LEADER_NOT_AVAILABLE pouvait signifier. J’espère que cela peut aider quelqu’un.

    Cette ligne ci-dessous, j’ai ajouté dans config/server.properties , qui a résolu mon problème problème ci-dessus. J’espère que cela vous aidera, c’est bien documenté dans le fichier server.properties, essayez de lire et de comprendre avant de le modifier. advertised.listeners=PLAINTEXT://:9092

    Le problème est résolu après l’ajout du paramètre d’écoute sur le fichier server.properties situé dans le répertoire config. listeners = PLAINTEXT: // localhost (ou votre serveur): 9092 Redémarrez kafka après cette modification. Version utilisée 2.11

    Lorsque l’erreur LEADER_NOT_AVAILABLE se produit, redémarrez simplement le courtier kafka:

     /bin/kafka-server-stop.sh 

    suivi par

     /bin/kafka-server-start.sh config/server.properties 

    (Remarque: Zookeeper doit fonctionner à ce moment-là, sinon vous ne fonctionnerez pas)

    Pour moi, c’était dû à une mauvaise configuration
    Port Docker (9093)
    Port de commande Kafka “bin / kafka-console-producer.sh –broker-list localhost: 9092 –topic TopicName”
    J’ai vérifié ma configuration pour correspondre au port et maintenant tout va bien

    J’ai été témoin de ce même problème au cours des deux dernières semaines lorsque je travaillais avec Kafka et lisais depuis cette publication.

    Après 2 semaines d’parsing, j’ai déduit que, dans mon cas, cela se produit lorsque j’essaie de produire des messages sur un sujet qui n’existe pas .

    Le résultat dans mon cas est que Kafka envoie un message d’erreur mais crée en même temps le sujet qui n’existait pas auparavant. Donc, si j’essaye encore de produire un message sur ce sujet après cet événement, l’erreur n’apparaîtra plus comme le sujet créé.

    S’IL VOUS PLAÎT NOTE: Il se peut que mon installation Kafka particulière a été configurée pour créer automatiquement le sujet au cas où il n’existerait pas, ce qui explique pourquoi dans mon cas, je ne vois le problème qu’une seule fois au début: Dans ce cas, vous continuerez à avoir la même erreur encore et encore.

    Cordialement,

    Luca Tampellini