GuiGui's Show - Liens
Ce que je retiens de Kafka : mécanisme de transmission de messages / queue , réparti, conserve l'ordre des messages, l'unité pour le passage à l'échelle est la partition.

Pour les cas d'utilisation possibles, voir : https://kafka.apache.org/documentation.html#uses. Je m'en sers pour injecter et conserver un flux Netflow (provenant d'un gros réseau), ce qui me permet d'alimenter un cluster Storm qui réalise un traitement sur ce Netflow (enrichissement + production de stats).

Notons que Kafka utilise Zookeeper pour stocker les membres du cluster, les partitions ainsi que les derniers offsets consommés par les clients dans chaque topic. Notons qu'un producteur n'a pas besoin d'aller chercher des infos dans Zookeeper : il contacte simplement un broker qui, via le protocole Kafka, lui indiquera les topics, les partitions et les replicats. Un consommateur a forcément besoin de s'enregistrer auprès de Zookeeper (dernier offset consommé). Pour ceux que ça intéresse : Zookeeper repose en partie sur les algorithmes de Lamport. ;)

Notons que si l'on a besoin d'avoir un cluster mi-privé (un cluster dans lesquels les membres doivent se parler via un réseau cloisonné adressé en RFC1918 mais où des clients externes doivent aussi joindre les Kafka, il y a une directive de configuration pour cela, « advertised.host.name » pour s'enregistrer différemment dans Zookeeper et fournir les bons noms dans les métas-données échangés avec un client. Sauf que ce n'est pas terriblement efficace et que je préfère traiter le problème via un mécanisme de nommage (DNS ou /etc/hosts) qui est fait pour ça. Voir : http://shaarli.guiguishow.info/?PazcBw

Comme dans tous les systèmes répartis, quand ça marche, ça juste marche bien et ça dépote mais quand ça chie, le debug est vraiment galère : identifier la partition qui pose problème dans les logs qui savoir quel logiciel produit et consomme dans cette partition puis... D'autant plus que les messages d'erreur de Kafka sont loin d'être explicites. Exemples :
   * Dans les logs d'un producteur : « Could not create kafka client : kafka server: Replica infomation not available, one or more brokers are down. » -> la machine leader pour une partition doit être en rade. Il faut arrêter les consommateurs Kafka, reboot la machine kafka en rade et fsck les partitions utilisées par Kafka. Refaire partir kafka. Les producteur devraient remonter.

   * Dans les logs d'un broker (server.log.<date>), Kafka se plaint d'index invalides lors d'une reprise après incident. Il faut stopper le broker et supprimer les fichiers d'index invalides dans le dossier data de Kafka (mv /kafka/<ID_partition>/*/*.index ~/backup/)

   * Dans les logs d'un broker (server.log.<date>), Kafka se plaint que les index demandés sont trop vieux : vos consommateurs sont à la traîne. Soit il y a un problème de leur côté, soit il faut augmenter la durée de conservation des données dans Kafka.

   * Le message le plus incompréhensible est celui d'un Kafka qui refuse de démarrer, prétextant un fichier d'index invalide alors qu'il n'y a aucun fichier dans le dossier de données ! Il faut vérifier à ce qu'il n'y ait aucun fichier caché, en fait. Cela arrive quand vous monter des partitions fraîchement créées dans le dossier de données (cas d'usage : plusieurs partitions sur plusieurs SSD dans l'optique de répartir la charge).
(Permalink)