Dépannage des défaillances de courtiers Kafka et stratégies de récupération

Lorsqu'un courtier Kafka tombe en panne, le symptôme bruyant se manifeste généralement ailleurs en premier : les consommateurs prennent du retard, les producteurs commencent à expirer, les tableaux de bord montrent des partitions sous-répliquées, ou un pipeline de déploiement se bloque parce qu'un événement n'arrive jamais. Le courtier lui-même peut seulement montrer un fait brutal : le processus a disparu, est bloqué au démarrage, ou est vivant mais trop lent pour être utile.

La manière utile de dépanner les défaillances de courtiers Kafka est de séparer rapidement trois questions. Le processus du courtier a-t-il planté ? Le nœud ou le disque a-t-il rendu le courtier malsain ? Ou le courtier fonctionne-t-il mais est-il incapable de participer correctement au cluster ? Ces chemins mènent à des correctifs différents, et les mélanger est ainsi que de petites pannes se transforment en longues.

Comprendre les défaillances de courtiers Kafka

Les courtiers Kafka peuvent tomber en panne pour diverses raisons, allant de problèmes matériels à des mauvaises configurations logicielles. Identifier la cause profonde est la première étape vers une récupération efficace. Voici quelques-uns des coupables les plus courants :

1. Problèmes matériels et d'infrastructure

• Défaillance du disque : Conduit souvent à des IOException ou LogSegmentCorruptedException dans les journaux. Les courtiers dépendent fortement des E/S disque pour le stockage persistant des messages.
• Épuisement de la mémoire (OOM) : Une RAM insuffisante peut provoquer le crash de la JVM ou le système d'exploitation tuant le processus Kafka. Les symptômes incluent OutOfMemoryError dans les journaux ou des messages du tueur OOM au niveau du système.
• Surcharge CPU : Une utilisation élevée du CPU peut ralentir considérablement les courtiers, entraînant des délais d'attente et une absence de réponse.
• Pannes de courant : Les arrêts non contrôlés peuvent corrompre les segments de journal ou les données de Zookeeper, surtout si les paramètres fsync ne sont pas optimaux.

2. Problèmes réseau

• Problèmes de connectivité : Les courtiers peuvent perdre la connexion avec d'autres courtiers, Zookeeper ou les clients. Cela peut se manifester par des NetworkException, SocketTimeoutException ou une expiration de session Zookeeper.
• Latence élevée/Perte de paquets : Des performances réseau dégradées peuvent entraîner un retard de réplication, des rééquilibrages de groupes de consommateurs et des échecs d'élection de courtier.

3. Configuration JVM et OS

• Paramètres de tas JVM incorrects : Si le tas est trop petit, une OutOfMemoryError se produit. S'il est trop grand, des pauses excessives de garbage collection (GC) peuvent rendre le courtier apparemment non réactif.
• Limites de descripteurs de fichiers : Kafka ouvre de nombreux fichiers (segments de journal, connexions réseau). Dépasser la ulimit du système d'exploitation pour les descripteurs de fichiers peut provoquer des erreurs Too many open files.
• Swapping : Lorsque le système d'exploitation commence à échanger la mémoire sur le disque, les performances se dégradent sévèrement. Les nœuds Kafka devraient idéalement avoir le swapping désactivé.

4. E/S disque et stockage

• Débit disque insuffisant : Si le disque ne peut pas suivre les demandes d'écriture, cela peut entraîner une attente d'E/S élevée, une accumulation de messages et finalement une absence de réponse du courtier.
• Disque plein : Un disque plein empêche Kafka d'écrire de nouveaux messages, conduisant à une IOException: No space left on device et à l'arrêt du courtier.
• Corruption du journal : Dans de rares cas, surtout après un arrêt incorrect, les segments de journal peuvent être corrompus, empêchant le courtier de démarrer ou de servir des données.

5. Problèmes de quorum de métadonnées ou de Zookeeper

• Indisponibilité de Zookeeper : Les clusters Kafka qui utilisent encore Zookeeper en dépendent pour la gestion des métadonnées, y compris l'élection du contrôleur et les métadonnées des sujets. Si Zookeeper est en panne ou lent, les courtiers peuvent montrer une expiration de session, un changement de contrôleur ou des problèmes de synchronisation des métadonnées.
• Problèmes de contrôleur KRaft : Les déploiements Kafka plus récents peuvent utiliser le mode KRaft au lieu de Zookeeper. Dans ces clusters, la santé du quorum du contrôleur est importante. Recherchez l'instabilité de l'élection du contrôleur, les problèmes de connectivité du quorum et les journaux de courtier mentionnant la réplication du journal des métadonnées.

6. Bugs logiciels et erreurs de configuration

• Bugs logiciels Kafka : Moins courants dans les versions stables mais possibles, surtout avec les versions plus récentes ou des cas particuliers spécifiques.
• Mauvaise configuration : Des paramètres server.properties incorrects (par exemple, listeners, advertised.listeners, log.dirs, implications de replication.factor) peuvent empêcher un courtier de rejoindre le cluster ou de fonctionner correctement.

Étapes de dépannage systématique

Lorsqu'un courtier Kafka tombe en panne, une approche systématique est essentielle pour identifier et résoudre rapidement le problème.

1. Évaluation initiale : Vérifier l'état de base

• Vérifier si le processus Kafka est en cours d'exécution :

  systemctl status kafka # Pour le service systemd
  # OU
  ps aux | grep -i kafka | grep -v grep
  

• Vérifier la connectivité du courtier depuis d'autres courtiers/clients :

  netstat -tulnp | grep <kafka_port>
  # OU utiliser nc pour tester le port depuis une autre machine
  nc -zv <broker_ip> <kafka_port>
  

2. Surveiller les ressources système

Utilisez des outils comme top, htop, free -h, iostat, df -h et vmstat pour vérifier :

• Utilisation CPU : Est-elle constamment élevée ? Y a-t-il beaucoup de cycles d'attente d'E/S ?
• Utilisation mémoire : Le système est-il proche de OOM ? Y a-t-il un swapping excessif ?
• E/S disque : Latence élevée en lecture/écriture ou saturation du débit ? Utilisez iostat -x 1 pour identifier les goulots d'étranglement du disque.
• Espace disque : La partition log.dirs est-elle pleine ? df -h <kafka_log_directory>
• Activité réseau : Y a-t-il des pics ou des chutes inhabituels dans le trafic ? Des taux d'erreur élevés ?

3. Analyser les journaux du courtier Kafka

Les journaux Kafka (kafka-logs/server.log par défaut) sont votre outil de diagnostic le plus important. Recherchez :

• Messages d'erreur : Messages de niveau ERROR, WARN précédant immédiatement la panne.
• Exceptions : OutOfMemoryError, IOException, SocketTimeoutException, LogSegmentCorruptedException.
• Activité GC : Longues pauses GC (indiquées par des messages INFO des journaux GC, si activés).
• Problèmes de connexion Zookeeper : Messages INFO concernant l'expiration ou le rétablissement de session.
• Élection du contrôleur : Messages liés au contrôleur Kafka et à son processus d'élection.

Astuce : Augmentez la rétention des journaux et activez la journalisation GC en production pour une meilleure analyse post-mortem.

4. Diagnostics JVM

Si la mémoire ou le CPU semble être un problème, utilisez des outils spécifiques à la JVM :

• jstat -gc <pid> 1000 : Surveillez les statistiques de garbage collection. Recherchez un nombre élevé de FGC (Full GC) ou un temps FGCT (Full GC Time) long.
• jstack <pid> : Obtenez un thread dump pour voir ce que fait la JVM. Utile pour identifier les deadlocks ou les opérations de longue durée.
• jmap -heap <pid> : Affiche l'utilisation de la mémoire du tas.
• jcmd <pid> GC.heap_dump <file> : Créez un heap dump pour une analyse détaillée de la mémoire avec des outils comme Eclipse MAT.

5. Vérification de l'état de la couche de métadonnées

Vérifiez le système de métadonnées que votre cluster utilise réellement.

Pour les clusters basés sur Zookeeper :

• Vérifier l'état du service Zookeeper :

  systemctl status zookeeper
  

• Vérifier les fichiers journaux de Zookeeper : Recherchez les problèmes de connexion depuis Kafka, les problèmes d'élection au sein de l'ensemble Zookeeper.
• Utiliser zkCli.sh pour se connecter à Zookeeper et lister les znodes liés à Kafka : ls /brokers/ids, ls /controller.

Pour les clusters basés sur KRaft, inspectez les journaux du contrôleur et du courtier ensemble. Si les courtiers sont sains au niveau du système d'exploitation mais ne peuvent pas s'enregistrer ou récupérer les métadonnées, le quorum du contrôleur est l'endroit à vérifier ensuite.

6. Révision de la configuration

Comparez le server.properties du courtier défaillant avec un courtier fonctionnel. Recherchez des différences subtiles ou des changements récents, en particulier log.dirs, listeners, advertised.listeners, broker.id et zookeeper.connect.

Stratégies de récupération efficaces

Une fois que vous avez identifié le problème, mettez en œuvre la stratégie de récupération appropriée.

1. Décider si un redémarrage est réellement sûr

Le redémarrage est raisonnable après avoir capturé les preuves dont vous avez besoin : journaux récents du courtier, journaux système, état du disque et la liste des partitions sous-répliquées ou hors ligne. Redémarrer trop tôt peut effacer un état de processus utile et faire ressembler un crash récurrent à cinq incidents non liés.

# Arrêter Kafka
systemctl stop kafka
# Vérifier les journaux pour les messages d'arrêt gracieux
# Démarrer Kafka
systemctl start kafka
# Surveiller les journaux pour les problèmes de démarrage

Si le courtier plante de manière répétée, arrêtez de considérer le redémarrage comme un correctif. À ce stade, ce n'est qu'un test. Surveillez le journal de démarrage dès la première ligne, car Kafka vous dit généralement s'il est bloqué sur la récupération du journal, la liaison d'écoute, l'accès au stockage, l'enregistrement des métadonnées ou le démarrage de la JVM.

2. Remplacement du matériel/VM défaillant

Pour les pannes matérielles permanentes (disque, mémoire, CPU), la solution est de remplacer la machine ou la VM défectueuse. Assurez-vous que la nouvelle instance a le même nom d'hôte/IP (si statique), les mêmes points de montage et la même configuration Kafka. Si les répertoires de données sont perdus, Kafka répliquera les données depuis d'autres courtiers une fois qu'il rejoindra le cluster, en supposant que replication.factor > 1.

Avant de ramener le remplacement, confirmez les règles d'identité du courtier pour votre déploiement. Réutiliser un ID de courtier avec les mauvais répertoires de journal peut causer de la confusion. Démarrer un courtier avec un nouvel ID alors que le cluster s'attend toujours à l'ancien peut également laisser des répliques attribuées à un courtier qui n'existe plus. Dans les remplacements planifiés, mettez à jour les attributions de répliques délibérément au lieu de compter sur le cluster pour résoudre un état ambigu.

3. Récupération des données et corruption du journal

Si les segments de journal sont corrompus (par exemple, LogSegmentCorruptedException), le courtier peut ne pas démarrer.

• Option A : Supprimer les journaux corrompus (si le facteur de réplication le permet) : Si replication.factor pour les sujets concernés est supérieur à 1 et qu'il existe des répliques saines, vous pouvez supprimer les répertoires de journal corrompus pour les partitions problématiques sur le courtier défaillant. Kafka répliquera ensuite les données.

  1. Arrêtez le courtier Kafka.
  2. Identifiez l'entrée log.dirs corrompue à partir des journaux.
  3. Supprimez manuellement les répertoires de partition dans log.dirs qui causent des problèmes (par exemple, rm -rf /kafka-logs/topic-0).
  4. Redémarrez le courtier.

• Option B : Utiliser l'outil kafka-log-dirs.sh : Cet outil peut être utilisé pour réattribuer des répliques ou déplacer des répertoires de journal. Pour la corruption du journal, une approche plus agressive peut être nécessaire. Les versions de Kafka ont souvent des outils internes pour des scénarios de récupération spécifiques, mais la suppression manuelle est courante pour les segments vraiment corrompus si des répliques existent ailleurs.

4. Réplication des partitions (si perdues)

Si un courtier tombe en panne et que ses données sont perdues de façon permanente (par exemple, crash de disque avec replication.factor=1 ou multiples pannes dépassant le facteur de réplication), certaines données peuvent être irrécupérables. Cependant, si replication.factor > 1, Kafka élira automatiquement de nouveaux leaders et récupérera les données. Vous pourriez avoir besoin d'utiliser kafka-reassign-partitions.sh pour rééquilibrer le leadership ou réattribuer des partitions à des courtiers sains si le courtier défaillant est définitivement hors service.

5. Mise à jour des configurations

Si la panne était due à une mauvaise configuration, corrigez server.properties et redémarrez le courtier. Pour les problèmes liés à la JVM (par exemple, OutOfMemoryError), ajustez KAFKA_HEAP_OPTS dans kafka-server-start.sh ou kafka-run-class.sh et redémarrez.

# Exemple : Augmenter la taille du tas
export KAFKA_HEAP_OPTS="-Xmx8G -Xms8G"
# Puis démarrer Kafka

6. Planification de la capacité et mise à l'échelle

L'épuisement constant des ressources (CPU, mémoire, E/S disque, réseau) indique un besoin de mise à l'échelle. Cela peut impliquer :

• Ajouter plus de courtiers au cluster.
• Mettre à niveau le matériel des courtiers existants.
• Optimiser les configurations des sujets (par exemple, num.partitions, segment.bytes).
• Améliorer l'efficacité des consommateurs.

Un flux de triage pratique

Lorsque vous êtes sous pression, ne commencez pas par toutes les commandes Kafka que vous connaissez. Commencez par le plus petit ensemble qui vous indique où se trouve la panne.

D'abord, vérifiez si le processus du courtier est vivant et à l'écoute :

systemctl status kafka
ss -lntp | grep 9092
jps -l | grep kafka

Si le processus est en panne, le journal du courtier et le journal système sont les preuves principales. Recherchez la première erreur grave, pas la dernière. La dernière ligne peut simplement dire que le serveur s'est arrêté ; la ligne utile est souvent quelques centaines de lignes plus tôt lorsque Kafka n'a pas réussi à ouvrir un répertoire de journal, à lier un écouteur, à allouer le tas ou à se connecter à la couche de métadonnées.

Si le processus est vivant, demandez-vous si le cluster le considère toujours comme utile :

kafka-broker-api-versions.sh --bootstrap-server <broker-host>:9092
kafka-topics.sh --bootstrap-server <bootstrap-host>:9092 --describe --under-replicated-partitions

Un courtier peut être vivant du point de vue du système d'exploitation et être un mauvais courtier du point de vue du cluster. Par exemple, il peut accepter des connexions TCP mais échouer aux requêtes parce qu'il ne peut pas lire depuis un disque lent. Ou il peut être accessible depuis votre ordinateur portable mais pas depuis d'autres courtiers parce que advertised.listeners pointe vers la mauvaise adresse.

Ensuite, vérifiez le nœud :

df -h
iostat -x 1
free -h
dmesg -T | tail -100

Le modèle le plus courant dans le monde réel n'est pas un mystérieux bug Kafka. C'est un disque plein, un disque mourant, un voisin bruyant sur le même hôte, une JVM sous pression mémoire, ou une incompatibilité d'écouteur/réseau introduite lors d'un changement de configuration.

Ce que l'erreur signifie généralement

No space left on device est direct. Libérez de l'espace ou ajoutez du stockage avant de redémarrer. Vérifiez également si les paramètres de rétention font ce que vous pensez qu'ils font. Un sujet avec une rétention étonnamment longue ou un sujet compacté avec une progression lente du nettoyeur peut remplir les disques silencieusement.

Too many open files pointe vers la limite du système d'exploitation pour le processus Kafka. Kafka ouvre des fichiers de segments de journal et des sockets réseau, donc des valeurs par défaut basses sont risquées. Augmentez la limite de descripteurs de fichiers pour l'utilisateur du service et confirmez-la à partir du processus en cours d'exécution, pas seulement à partir d'une session shell.

OutOfMemoryError signifie que la JVM n'a pas pu allouer de mémoire, mais la cause n'est pas toujours "tas trop petit". Cela peut être une fuite, trop de partitions sur le courtier, un traitement de très grandes requêtes, ou un tas mal dimensionné qui laisse trop peu de mémoire pour le cache de pages du système de fichiers. Kafka dépend fortement du cache de pages du système d'exploitation, donc donner toute la RAM à la JVM peut aggraver le comportement du disque.

Connection to node -1 could not be established apparaît souvent lors du bootstrap du client et peut être causé par advertised.listeners. Si les clients peuvent se connecter à l'adresse de bootstrap mais reçoivent ensuite un nom d'hôte interne qu'ils ne peuvent pas résoudre, ils échouent après la première réponse de métadonnées.

Leader not available après une panne de courtier signifie généralement que le leadership est encore en mouvement ou que les partitions concernées n'ont pas de réplique en synchronisation prête. Vérifiez si le sujet a suffisamment de réplication et si min.insync.replicas est compatible avec le nombre de répliques actuellement saines.

Mesures préventives et meilleures pratiques

Des mesures proactives réduisent considérablement la probabilité et l'impact des défaillances de courtiers.

• Surveillance et alertes robustes : Mettez en œuvre une surveillance complète des ressources système (CPU, mémoire, E/S disque, réseau), des métriques JVM (GC, utilisation du tas) et des métriques spécifiques à Kafka (partitions sous-répliquées, état du contrôleur, retard du consommateur). Configurez des alertes pour les seuils critiques.
• Allocation appropriée des ressources : Provisionnez les courtiers avec suffisamment de CPU, de mémoire et de disques haute performance (les SSD sont fortement recommandés). Évitez la sursouscription dans les environnements virtualisés.
• Maintenance et mises à jour régulières : Maintenez Kafka et ses dépendances (JVM, OS) à jour pour bénéficier des corrections de bugs et des améliorations de performances. Testez les mises à jour en profondeur dans des environnements non productifs.
• Configuration haute disponibilité : Utilisez toujours un replication.factor supérieur à 1 (généralement 3) pour les sujets de production afin d'assurer la redondance des données et la tolérance aux pannes. Cela permet aux courtiers de tomber en panne sans perte de données ni interruption de service.
• Planification de la reprise après sinistre : Ayez un plan clair pour la récupération des données, y compris des sauvegardes régulières des configurations critiques et éventuellement des segments de journal (bien que la réplication de Kafka soit le mécanisme principal de reprise après sinistre pour les données).
• Désactiver le swapping : Assurez-vous que vm.swappiness=0 ou swapoff -a sur les machines des courtiers Kafka.
• Augmenter les limites de descripteurs de fichiers : Définissez une ulimit -n élevée pour l'utilisateur Kafka (par exemple, 128000 ou plus).

Après la récupération du courtier

Ne fermez pas l'incident dès que le courtier démarre. Vérifiez si les répliques ont rattrapé leur retard, si des partitions sont restées hors ligne et si les consommateurs récupèrent normalement.

kafka-topics.sh --bootstrap-server <bootstrap-host>:9092 --describe --under-replicated-partitions
kafka-consumer-groups.sh --bootstrap-server <bootstrap-host>:9092 --all-groups --describe

Notez également le signal exact de la première panne. "Le courtier est tombé en panne" n'est pas une cause racine. "Le courtier s'est arrêté après que le répertoire de journal /data2/kafka a renvoyé des erreurs d'E/S" est quelque chose que vous pouvez prévenir, surveiller et tester lors de la prochaine fenêtre de maintenance.