Leader non disponible Kafka dans le producteur de console


172

J'essaye 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 l'erreur suivante

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


quelle version de kafka utilisez-vous? comment savez-vous que toutes les configurations sont correctes? veuillez essayer d'ajouter plus d'informations
Nautilus

J'utilise la version 2.11-0.9.0.0, j'ai dit que toutes les configurations sont correctes car cela fonctionnait.
Vishesh

1
@Vishesh Pouvez-vous fournir le résultat de la commande suivante ./bin/kafka-topics.sh --zookeeper localhost: 2181 --describe --topic yourTopicName
avr

2
même erreur pour moi aussi. Je reçois le leader ./bin/kafka-topics.sh --zookeeper <ip>: 2181 --describe --topic yourTopicName mais lors de l'envoi du message au producteur, il génère l'erreur LEADER_NOT_AVAILABLE.
Vilva

2
Je peux confirmer ce problème sur kafka 2.2.0en 2019
javadba

Réponses:


94

Cela pourrait être lié à la advertised.host.nameconfiguration de votre server.properties.

Ce qui pourrait arriver, c'est que votre producteur essaie de savoir qui est le leader pour une partition donnée, comprend son advertised.host.nameet advertised.portet essaie de se connecter. Si ces paramètres ne sont pas configurés correctement, il peut alors penser que le leader n'est pas disponible.


1
Cela a corrigé l'erreur pour moi .. mais les commentaires dans server.properties indiquent que si advertised.host.name n'est pas configuré, il utilisera host.name. Et le host.name a été configuré dans le fichier server.properties.
Mr Spark

J'ai eu le même problème et cela a fonctionné pour moi pour kafka 0.9
minhas23

3
Définir ceci sur mon adresse IP au lieu du nom d'hôte public généré par AWS a résolu de nombreux problèmes que je rencontrais.
Spechal

81

J'ai essayé toutes les recommandations énumérées ici. Ce qui a fonctionné pour moi était d'aller server.propertieset d'ajouter:

port = 9092
advertised.host.name = localhost 

Laissez listenerset advertised_listenerscommenté.


5
la solution fonctionne pour moi ( lien de la solution de vikas ) Je veux juste ajouter que pour moi le server.propertiesfichier MAC se trouve à/usr/local/etc/kafka/
Edison Q

2
ce qui a fonctionné pour moi était ceci advertised.listeners=PLAINTEXT://my.ip:9092
M. Crowley

14
NE PAS UTILISER CECI - port, advertised.host.namesont des configurations obsolètes. kafka.apache.org/documentation/#brokerconfigs
Stephane

44

Ce qui a résolu le problème pour moi, c'est de définir les auditeurs comme ceci:

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

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


4
Cela devrait être la réponse acceptée. Fonctionne pour la configuration multi-nœuds et a beaucoup de sens.
Piyush Shrivastava

Pouvons-nous l'utiliser dans notre fichier app.yaml?
Codeur

40

J'avais kafka fonctionnant comme un conteneur Docker et des messages similaires inondaient le journal.
Et KAFKA_ADVERTISED_HOST_NAMEétait réglé sur «kafka».

Dans mon cas, la raison de l'erreur était l' /etc/hostsenregistrement manquant pour «kafka» dans le conteneur «kafka» lui-même.
Ainsi, par exemple, l'exécution ping kafkaà l' intérieur du conteneur 'kafka' échouerait avecping: bad address 'kafka'

En termes de Docker, ce problème est résolu en spécifiant hostnamele conteneur.

Options pour y parvenir:


Ce n'est pas une réponse en soi , mais pour référence future: quand (ou si) le docker / docker # 1143 est résolu, il y aura un moyen facile de référencer l'hôte du conteneur, quel que soit le système d'exploitation utilisé.
Michael Ahlers

Si vous utilisez l' image docker wurstmeister / kafka-docker (qui est probablement la plus populaire au moment de la rédaction de cet article), voir les notes ici concernant la configuration de cette
variable d'environnement

32

J'utilise kafka_2.12-0.10.2.1:

vi config/server.properties

ajouter ci-dessous la ligne:

listeners=PLAINTEXT://localhost:9092
  • Il n'est pas nécessaire de modifier le fichier 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 "écouteurs" si elle est configurée

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 voir aucun problème.


Cela a résolu le problème pour moi, la modification server.propertiesn'était pas suffisante jusqu'à ce que je redémarre le courtier avec un démon rechargé. Vous êtes peut-être censé le savoir, mais cela a certainement aidé à le préciser dans cette réponse
Bossan

Cela a fonctionné pour moi, merci beaucoup mon frère. J'utilisekafka 2.13
Alejandro Herrera

31

J'ai été témoin de ce même problème au cours des 2 dernières semaines en travaillant avec Kafka et j'ai lu ce post de Stackoverflow depuis.

Après 2 semaines d'analyse, 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 renvoie un message d'erreur mais crée, en même temps, le sujet qui n'existait pas auparavant. Donc, si j'essaie de produire à nouveau un message sur ce sujet après cet événement, l'erreur n'apparaîtra plus comme le sujet tel qu'il a été créé.

VEUILLEZ NOTER: Il se peut que mon installation particulière de Kafka ait été configurée pour créer automatiquement le sujet lorsque celui-ci n'existe pas; cela devrait expliquer pourquoi, dans mon cas, je ne peux voir le problème qu'une seule fois pour chaque sujet après la réinitialisation des sujets: votre configuration peut être différente et dans ce cas, vous continuerez à recevoir la même erreur encore et encore.

Cordialement,

Luca Tampellini


Salut Luca. Je crée également automatiquement de nouveaux sujets. Ma question est de savoir comment permettre à vos consommateurs de découvrir automatiquement ce nouveau sujet? Mes consommateurs ne le feront pas. Et après avoir redémarré mes consommateurs, de nouveaux messages peuvent être reçus, mais le message qui a provoqué la création du sujet est perdu.
jchnxu

15

Nous avons tendance à recevoir ce message lorsque nous essayons de nous 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 kafka dockerisée, qui commence à nettoyer à 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 pile pour en savoir plus sur la configuration d'AdminUtils.


8

Une autre possibilité pour cet avertissement (en 0.10.2.1) est que vous essayez de sonder sur un sujet qui vient d'être créé et que le leader de cette partition-sujet n'est pas encore disponible, vous êtes au milieu d'une élection à la direction.

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


6

Pour quiconque essaie d'exécuter kafka sur kubernetes et rencontre cette erreur, c'est ce qui l'a finalement résolu pour moi:

Vous devez soit:

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

ou

  1. Si vous utilisez hostPort, vous avez besoin hostNetwork: trueetdnsPolicy: ClusterFirstWithHostNet

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

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

2
1. ne fonctionne pas% ERREUR: Local: Échec de la résolution de l'hôte: kafka-cluster: 9092/1001: Échec de la résolution de «kafka-cluster: 9092»: nom de nœud ni nom de service fourni, ou
inconnu

J'ai ajouté le nom d'hôte comme le nom du service, travaillant pour moi!
karthikeayan

6

Ajouter ceci car cela peut aider les autres. Un problème courant peut être une mauvaise configuration de advertised.host.name. Avec Docker utilisant le paramètre docker-compose, le nom du service à l'intérieur KAFKA_ADVERTISED_HOST_NAMEne fonctionnera pas à moins que vous ne définissiez également le nom d'hôte. docker-compose.ymlexemple:

  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

Ce qui précède sans hostname: kafkapeut générer un problème LEADER_NOT_AVAILABLElors de la tentative de connexion. Vous pouvez trouver un exemple de docker-composeconfiguration de travail ici


6

Dans mon cas, cela fonctionnait bien à la maison, mais cela échouait au bureau, au moment où je me connectais au réseau de bureau.

Donc modifié le config / server.properties listeners = PLAINTEXT: //: 9092 to listeners = PLAINTEXT: // localhost: 9092

Dans mon cas, j'obtenais en décrivant le groupe de consommateurs


Pourquoi diable ne définissent-ils pas les valeurs par défaut correctes, cela m'a aidé.
poudre366

5

Si vous exécutez kafka sur une machine locale, essayez de mettre à jour $ KAFKA_DIR / config / server.properties avec la ligne ci-dessous: listeners=PLAINTEXT://localhost:9092puis redémarrez kafka.


comment faire cela sur docker-compose.yml?
AC28

Vous pouvez utiliser un script shell de point d'entrée docs.docker.com/compose/compose-file/#entrypoint avec les écouteurs docker compose et overwrite (sed) dans server.properties.
MrKulli

3

J'utilise docker-compose pour créer le conteneur Kafka en utilisant l' wurstmeister/kafkaimage. L'ajout d'une KAFKA_ADVERTISED_PORT: 9092propriété à mon docker-composefichier a résolu cette erreur pour moi.


3

Puisque je voulais que mon courtier kafka se connecte avec des producteurs et des consommateurs à distance, je ne veux donc advertised.listenerpas être commenté. Dans mon cas, (exécutant kafka sur kubernetes), j'ai découvert que mon pod kafka n'avait pas d'IP de cluster. En supprimant la ligne clusterIP: Nonede services.yml, le kubernetes attribue une ip interne au pod kafka. Cela a résolu mon problème de LEADER_NOT_AVAILABLE et également la connexion à distance des producteurs / consommateurs de kafka.


3

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 être en cours d'exécution à cette heure, si vous faites autrement, cela ne fonctionnera pas)


Oui. se produit lorsque kafka est démarré en premier et le gardien de zoo après.
panchicore

J'ai fait cela et cela ne résout pas tout à fait le problème. Ce qui est étrange, c'est que le courtier s'initialise comme s'il était le leader. comme dans New leader is 0.
Sammy

2

Cette ligne ci-dessous que j'ai ajoutée a config/server.propertiesrésolu mon problème similaire au problème ci-dessus. J'espère que cela aide, c'est assez bien documenté dans le fichier server.properties, essayez de lire et de comprendre avant de modifier cela. advertised.listeners=PLAINTEXT://<your_kafka_server_ip>:9092


1

Pour tous ceux qui luttent avec la configuration de Kafka ssl et voient cette erreur LEADER_NOT_AVAILABLE. L'une des raisons qui pourraient être brisées est le keystore et le truststore. Dans le keystore, vous devez avoir la clé privée du serveur + le certificat de serveur signé. Dans le magasin de clés de confiance client, vous devez disposer d'un certificat CA intermédiaire afin que le client puisse authentifier le serveur kafka. Si vous souhaitez utiliser ssl pour la communication entre courtiers, vous devez également définir ce truststore dans le server.properties des courtiers afin qu'ils puissent s'authentifier mutuellement.

Cette dernière pièce que j'ai manquée par erreur m'a causé beaucoup d'heures douloureuses pour découvrir ce que pouvait signifier cette erreur LEADER_NOT_AVAILABLE. J'espère que cela peut aider quelqu'un.


Qu'entendez-vous par «clé privée du serveur»? J'ai la clé CA et le certificat de serveur signé dans le keystore du serveur alors que dans le truststore du client, j'ai le certificat CA. Mais j'obtiens toujours ces erreurs ..
phaigeim

Désolé, je voulais dire clé privée + certificat. J'étais en train de créer un grand cluster et quelque part dans la chaîne de la bureaucratie a fait une erreur, donc l'un des certificats ne correspondait pas à la RSE. Cela pourrait également être une autre raison. Vérifiez que md5 de la clé privée, du certificat correspond et que ce certificat peut être vérifié avec votre truststore. Truststore contient généralement des certificats racine et intermédiaire (s)
vojtmen

1

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


0

Pour moi, cela était dû à une configuration manquante du
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


0

Pour moi, la cause était l'utilisation d'un gardien de zoo spécifique qui ne faisait pas partie du package Kafka. Ce Zookeeper était déjà installé sur la machine à d'autres fins. Apparemment, Kafka ne fonctionne pas avec n'importe quel gardien de zoo. Le passage au gardien de zoo fourni avec Kafka a résolu le problème pour moi. Pour ne pas entrer en conflit avec le Zookeeper existant, j'ai dû modifier ma configuration pour que le Zookeeper écoute sur un port différent:

[root@host /opt/kafka/config]# grep 2182 *
server.properties:zookeeper.connect=localhost:2182
zookeeper.properties:clientPort=2182

0

Les auditeurs annoncés comme mentionnés dans les réponses ci-dessus pourraient en être une des raisons. Les autres raisons possibles sont:

  1. Le sujet n'a peut-être pas été créé. Vous pouvez vérifier cela en utilisantbin/kafka-topics --list --zookeeper <zookeeper_ip>:<zookeeper_port>
  2. Vérifiez vos serveurs d'amorçage que vous avez donnés au producteur pour récupérer les métadonnées. Si le serveur d'amorçage ne contient pas les dernières métadonnées sur le sujet (par exemple, lorsqu'il a perdu sa revendication de gardien de zoo). Vous devez ajouter plusieurs serveurs d'amorçage.

Assurez-vous également que l'auditeur annoncé est défini sur au IP:9092lieu de localhost:9092. Ce dernier signifie que le courtier est accessible uniquement via l'hôte local.

Quand j'ai rencontré l'erreur, je me souviens de l'avoir utilisé PLAINTEXT://<ip>:<PORT>dans la liste des serveurs bootstrap (ou la liste des courtiers) et cela a fonctionné, étrangement.

bin/kafka-console-producer --topic sample --broker-list PLAINTEXT://<IP>:<PORT>

0

Pour moi, je n'ai pas spécifié d'ID de courtier pour l'instance Kafka. Il obtiendra parfois un nouvel identifiant de zookeeper lorsqu'il redémarrera dans l'environnement Docker. Si votre ID de courtier est supérieur à 1 000, spécifiez simplement la variable d'environnement KAFKA_BROKER_ID.

Utilisez ceci pour voir les courtiers, les sujets et les partitions.

brew install kafkacat
kafkacat -b [kafka_ip]:[kafka_poot] -L

0

Je sais que cela a été posté il y a longtemps, je voudrais partager comment je l'ai résolu.
depuis que j'ai mon ordinateur portable de bureau ( VPN et proxy a été configuré).
j'ai vérifié la variable d'environnement NO_PROXY

> echo %NO_PROXY%

il est retourné avec des valeurs vides
maintenant j'ai défini le NO_PROXY avec localhost et 127.0.0.1

> set NO_PROXY=127.0.0.1,localhost  

si vous souhaitez ajouter aux valeurs existantes, alors

> set NO_PROXY=%NO_PROXY%,127.0.0.1,localhost  

après cela, j'ai redémarré le gardien de zoo et kafka a
fonctionné comme un charme

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.