Kafka Producer NetworkException et exceptions d'expiration
Nous obtenons de façon aléatoireNetworkExceptionsetTimeoutExceptionsdans notre environnement de production:
Brokers: 3
Zookeepers: 3
Servers: 3
Kafka: 0.10.0.1
Zookeeeper: 3.4.3
Nous avons parfois cette exception dans mes journaux de producteurs:
Date d'expiration 10 enregistrement (s) pour TOPIC: XXXXXX: 5608 ms s'est écoulé depuis le lot création plus le temps passé.
Le nombre de millisecondes dans de tels messages d'erreur ne cesse de changer. Parfois, c'est ~ 5 secondes, parfois jusqu'à ~ 13 secondes!
Et très rarement nous obtenons:
NetworkException: Server disconnected before response received.
Le cluster est constitué de 3 courtiers et 3 zookeepers. Le serveur de production et le cluster Kafka sont sur le réseau même.
Je passe des appels synchrones. Il existe un service Web sur lequel plusieurs utilisateurs demandent à envoyer leurs données. Le service Web Kafka a un objet Producer qui effectue tous les envois. Le délai d'expiration de la demande du producteur était initialement de 1000 ms; il a été initialement remplacé par 15000 ms (15 secondes). Même après l’augmentation du délai d’expirationTimeoutExceptionsapparaissent toujours dans les journaux d’erreur.
Quelle peut être la raison?
C’est un peu délicat de trouver la cause fondamentale, je vais laisser tomber mon expérience là-dessus, j'espère que quelqu'un le trouvera utile. En général, il peut s'agir d'un problème de réseau ou d'une inondation excessive du réseau, associée à ack=ALL. Voici un diagramme qui explique la TimeoutException de Kafka KIP-91 au moment de la rédaction (toujours applicable jusqu’au 1.1.0):
En excluant les problèmes ou les erreurs de configuration réseau, ce sont les propriétés que vous pouvez ajuster en fonction de votre scénario afin d'atténuer ou de résoudre le problème:
Buffer.memory contrôle la mémoire totale disponible pour un producteur en mémoire tampon. Si les enregistrements sont envoyés plus rapidement qu'ils ne peuvent être transmis à Kafka, et que cette mémoire tampon sera dépassée, des appels d'envoi supplémentaires seront bloqués jusqu'à max.block.ms après que Producer jette une
TimeoutException.Max.block.ms a déjà une valeur élevée et je ne suggère pas de l'incrémenter davantage. buffer.memory a la valeur par défaut de 32 Mo. Selon la taille du message, vous souhaiterez peut-être l'augmenter. Si nécessaire, augmentez l’espace jvm.
Retries définissent le nombre de tentatives d'envoi de l'enregistrement en cas d'erreur avant l'abandon. Si vous utilisez zéro tentative, vous pouvez essayer d'atténuer le problème en augmentant cette valeur. Attention, l'ordre des enregistrements n'est plus garanti, sauf si vous définissez max.in.flight.requests.per.connection sur 1.
Les enregistrements sont envoyés dès que la taille du lot est atteinte ou que le temps d'attente est écoulé, selon la première éventualité. Si batch.size (16 Ko par défaut) est inférieur à la taille maximale de la demande, vous devez peut-être utiliser une valeur plus élevée. En outre, remplacez linger.ms par une valeur plus élevée, telle que 10, 50 ou 100, afin d’optimiser l’utilisation du lot et la compression. Cela entraînera moins d'inondations sur le réseau et optimisera la compression si vous l'utilisez.
Il n’existe pas de réponse exacte à ce type de problèmes car ils dépendent également de la mise en œuvre. Dans mon cas, l’expérimentation des valeurs ci-dessus a aidé.
Solution 1
Modifier
listeners=PLAINTEXT://hostname:9092
propriété dans le fichier server.properties à
listeners=PLAINTEXT://0.0.0.0:9092
Solution 2
Remplacez broker.id par une valeur telle que 1001, modifiez l'ID brocker en définissant la variable d'environnement KAFKA_BROKER_ID.
Vous devez définir la variable d'environnement KAFKA_RESERVED_BROKER_MAX_ID sur quelque chose comme 1001 pour pouvoir définir l'identifiant du courtier sur 1001.
J'espère que ça peut aider
Incrémentez les request.timeout.ms et les tentatives de votre producteur