Leader non disponible Kafka dans le producteur de console

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

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.

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é.

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.

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:

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

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.

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

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.

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.

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

2. 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

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

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

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.

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.

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.

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)

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

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.

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

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

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

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>

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

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