Dépannage du décalage courant des consommateurs Kafka (Consumer Lag) à l'aide des commandes console

Kafka est une plateforme de streaming d'événements distribuée, reconnue pour son haut débit et sa tolérance aux pannes. Au cœur de nombreux systèmes basés sur Kafka se trouvent les consommateurs (consumers), des applications qui lisent et traitent des flux de données. Une métrique essentielle pour surveiller la santé et la performance de ces applications consommatrices est le décalage du consommateur (consumer lag).

Le décalage du consommateur fait référence au délai entre le dernier message écrit dans une partition de topic Kafka et le dernier message traité avec succès par un consommateur pour cette même partition. Un décalage élevé peut indiquer divers problèmes, allant de la lenteur de la logique du consommateur aux goulots d'étranglement de l'infrastructure, et peut entraîner des retards de traitement des données, des informations périmées, ou même une perte de données s'il n'est pas résolu rapidement. Cet article fournira un guide détaillé sur l'utilisation des commandes console Kafka essentielles pour diagnostiquer un décalage élevé, interpréter les résultats et, si nécessaire, réinitialiser efficacement les offsets afin de resynchroniser les consommateurs.

À la fin de ce guide, vous disposerez des connaissances pratiques nécessaires pour surveiller et dépanner efficacement les scénarios courants de décalage des consommateurs à l'aide de puissants outils de ligne de commande comme kafka-consumer-groups.sh, une compétence cruciale pour tout opérateur ou développeur Kafka.

Comprendre le décalage des consommateurs Kafka

Dans Kafka, les messages sont organisés en topics, qui sont ensuite divisés en partitions. Chaque message dans une partition se voit attribuer un offset séquentiel et immuable. Les consommateurs lisent les messages d'une partition en maintenant leur position actuelle, également appelée offset validé (committed offset). Le broker Kafka suit le log-end-offset pour chaque partition, qui représente l'offset du dernier message qui y a été ajouté.

Décalage du consommateur = Log-End-Offset - Committed Offset

Essentiellement, le décalage est le nombre de messages qu'un consommateur a de retard par rapport à la tête du journal pour une partition donnée. Bien qu'un certain décalage soit naturel et attendu dans tout système de streaming, un décalage croissant ou excessivement grand signale un problème.

Pourquoi un décalage élevé est une source de préoccupation :

• Traitement des données retardé : Vos applications pourraient traiter les données trop lentement, ce qui aurait un impact sur l'analyse en temps réel ou les opérations commerciales critiques.
• Épuisement des ressources : Les consommateurs pourraient avoir du mal à suivre, entraînant une utilisation élevée du CPU, de la mémoire ou du réseau.
• Données périmées : Les systèmes en aval recevant des données de consommateurs en retard fonctionneront avec des informations obsolètes.
• Problèmes de politique de rétention : Si le décalage dépasse la période de rétention du topic, les consommateurs risquent de manquer définitivement des messages lorsqu'ils sont purgés du journal.
• Rééquilibrages du groupe de consommateurs : Un décalage persistant peut contribuer à un comportement instable du groupe de consommateurs et à des rééquilibrages fréquents.

Causes courantes d'un décalage élevé :

• Logique du consommateur lente : L'application consommatrice elle-même met trop de temps à traiter chaque message.
• Instances de consommateur insuffisantes : Le nombre d'instances de consommateurs en cours d'exécution est insuffisant pour gérer le volume de messages sur toutes les partitions.
• Latence du réseau : Problèmes entre les consommateurs et les brokers.
• Problèmes de performance des brokers : Les brokers pourraient avoir du mal à servir les messages efficacement.
• Pics de production de messages : Surcharges temporaires de messages qui submergent les consommateurs.
• Erreurs de configuration : Configurations de consommateur ou de topic incorrectes.

Diagnostic du décalage avec kafka-consumer-groups.sh (Recommandé)

L'outil kafka-consumer-groups.sh est la manière moderne et recommandée de gérer et d'inspecter les groupes de consommateurs. Il interagit directement avec les brokers Kafka pour récupérer les informations d'offset du consommateur, qui sont stockées dans un topic interne __consumer_offsets. Cet outil fournit des détails complets sur l'état du groupe de consommateurs, y compris le décalage.

Utilisation de base pour décrire un groupe de consommateurs

Pour vérifier le décalage d'un groupe de consommateurs spécifique, utilisez les options --describe et --group :

kafka-consumer-groups.sh --bootstrap-server <Kafka_Broker_Host:Port> --describe --group <Consumer_Group_Name>

Remplacez <Kafka_Broker_Host:Port> par l'adresse d'un de vos brokers Kafka (par exemple, localhost:9092) et <Consumer_Group_Name> par le nom du groupe de consommateurs que vous souhaitez inspecter.

Interprétation de la sortie

Une sortie typique ressemblera à ceci :

GROUP           TOPIC                          PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG             CONSUMER-ID                                       HOST            CLIENT-ID
my-consumer-app my-topic                       0          12345           12347           2               consumer-1-a1b2c3d4-e5f6-7890-1234-abcdedfg      /192.168.1.100  consumer-1
my-consumer-app my-topic                       1          20000           20500           500             consumer-2-hijk-lmno-pqrs-tuvw-xyz              /192.168.1.101  consumer-2
my-consumer-app my-topic                       2          5000            5000            0               consumer-3-1234-5678-90ab-cdef-12345678          /192.168.1.102  consumer-3
my-consumer-app another-topic                  0          900             900             0               consumer-1-a1b2c3d4-e5f6-7890-1234-abcdedfg      /192.168.1.100  consumer-1

Analysons les colonnes importantes :

• GROUP : Le nom du groupe de consommateurs.
• TOPIC : Le topic consommé.
• PARTITION : La partition spécifique du topic.
• CURRENT-OFFSET : Le dernier offset validé par le consommateur pour cette partition.
• LOG-END-OFFSET : L'offset du dernier message dans cette partition.
• LAG : La différence entre LOG-END-OFFSET et CURRENT-OFFSET. C'est le nombre de messages de retard du consommateur.
• CONSUMER-ID : Un identifiant unique pour l'instance de consommateur. Si c'est -, cela signifie qu'aucun consommateur actif n'est assigné à cette partition.
• HOST : L'adresse IP ou le nom d'hôte de l'instance de consommateur.
• CLIENT-ID : L'ID client configuré pour l'instance de consommateur.

Observations clés :

• Valeurs LAG élevées : Indiquent que le consommateur prend du retard. Enquêtez sur la logique du consommateur, les ressources ou la mise à l'échelle.
• - dans CONSUMER-ID : Suggère qu'une partition n'est pas consommée. Cela pourrait être dû à un nombre insuffisant de consommateurs actifs dans le groupe ou à une instance de consommateur qui s'est écrasée sans se reconnecter. Si le LAG est élevé pour de telles partitions, c'est un problème critique.
• LAG de 0 : Signifie que le consommateur est totalement à jour avec les derniers messages.

Diagnostic du décalage avec consumer-offset-checker.sh (Outil hérité)

consumer-offset-checker.sh est un outil plus ancien et obsolète qui reposait sur ZooKeeper pour le stockage et la récupération des offsets des consommateurs (pour les consommateurs utilisant l'ancien kafka.consumer.ZookeeperConsumerConnector). Pour les clients Kafka modernes (0.9.0 et ultérieurs), les offsets sont stockés dans Kafka lui-même. Bien qu'il soit largement remplacé par kafka-consumer-groups.sh, vous pourriez le rencontrer dans des environnements plus anciens ou avec des clients consommateurs hérités.

Avertissement : Avis d'obsolescence (Deprecation Notice)

Cet outil repose sur ZooKeeper pour la gestion des offsets. Les clients Kafka modernes (0.9.0+) stockent les offsets directement dans Kafka. Pour les clusters et clients plus récents, kafka-consumer-groups.sh est l'outil faisant autorité et le plus préférable. N'utilisez consumer-offset-checker.sh que si vous savez explicitement que vos clients consommateurs sont configurés pour stocker les offsets dans ZooKeeper.

Utilisation de base

Pour vérifier le décalage avec cet outil, vous devez fournir la chaîne de connexion ZooKeeper :

consumer-offset-checker.sh --zk <ZooKeeper_Host:Port> --group <Consumer_Group_Name>

Remplacez <ZooKeeper_Host:Port> (par exemple, localhost:2181) et <Consumer_Group_Name>.

Interprétation de la sortie

Group           Topic                          Partition Offset  LogSize Lag     Owner
my-old-app      my-old-topic                   0         1000    1050    50      consumer-1_hostname-1234-5678-90ab-cdef
my-old-app      my-old-topic                   1         2000    2000    0       consumer-2_hostname-abcd-efgh-ijkl-mnop

• Group, Topic, Partition : Similaires à kafka-consumer-groups.sh.
• Offset : L'offset validé par le consommateur.
• LogSize : Le LOG-END-OFFSET de la partition.
• Lag : Le nombre de messages de retard du consommateur.
• Owner : L'instance de consommateur qui possède (consomme) actuellement la partition.

L'interprétation des valeurs de décalage est similaire : un décalage élevé indique des problèmes, et un Owner manquant pour une partition avec un décalage élevé est un problème critique.

Gérer un décalage élevé des consommateurs : Stratégies et réinitialisations d'offsets

Une fois que vous avez identifié un décalage élevé, l'étape suivante consiste à le résoudre. Cela implique souvent une approche à deux volets : premièrement, enquêter et corriger la cause profonde, et deuxièmement, si nécessaire, réinitialiser les offsets du consommateur.

Enquêter sur la cause profonde

Avant de procéder à la réinitialisation des offsets, il est crucial de comprendre pourquoi le décalage se produit. Vérifiez les points suivants :

• Journaux de l'application consommatrice (Consumer Application Logs) : Recherchez les erreurs, les temps de traitement excessifs ou les signes de défaillance de l'application.
• Métriques de l'hôte du consommateur (Consumer Host Metrics) : Surveillez l'utilisation du CPU, de la mémoire et du réseau. Le consommateur est-il limité par les ressources ?
• Métriques du broker Kafka : Les brokers sont-ils sous tension ? Les E/S disque, le réseau ou le CPU sont-ils élevés ?
• Débit du producteur (Producer Throughput) : Y a-t-il eu un pic inattendu dans la production de messages ?
• État du groupe de consommateurs (Consumer Group State) : Y a-t-il des rééquilibrages fréquents ? La valeur max.poll.interval.ms est-elle atteinte ?

Mise à l'échelle des consommateurs

Si le problème est que les consommateurs existants ne peuvent pas traiter les messages assez rapidement, et que le topic a suffisamment de partitions, vous pourriez avoir besoin d'augmenter la taille de votre groupe de consommateurs en ajoutant davantage d'instances. Chaque instance de consommateur dans un groupe prendra en charge une ou plusieurs partitions jusqu'à ce que toutes les partitions soient assignées, dans la limite du nombre de partitions.

Réinitialisation des offsets des consommateurs

La réinitialisation des offsets des consommateurs signifie changer le point de départ à partir duquel un groupe de consommateurs lira les messages. C'est une opération puissante, potentiellement perturbatrice, qui doit être utilisée avec prudence.

Considérations importantes avant de réinitialiser les offsets :

• Perte de données : La réinitialisation à --to-latest entraînera les consommateurs à sauter tous les messages entre leur offset actuel et le log-end-offset, conduisant à une perte de données permanente pour ces messages.
• Retraitement des données : La réinitialisation à --to-earliest ou à un offset plus ancien signifie que les consommateurs vont retraiter les messages qu'ils ont déjà gérés. Votre application consommatrice doit être idempotente (le traitement d'un message plusieurs fois donne le même résultat) pour gérer cela avec élégance.
• État de l'application : Considérez comment le retraitement pourrait affecter tout état géré par votre application consommatrice ou vos systèmes en aval.

Pour réinitialiser les offsets, vous utiliserez à nouveau kafka-consumer-groups.sh. Il offre diverses options pour la réinitialisation des offsets :

• --to-earliest : Réinitialise les offsets au plus ancien offset disponible dans la partition.
• --to-latest : Réinitialise les offsets au dernier offset dans la partition (sautant effectivement tous les messages actuels).
• --to-offset <offset> : Réinitialise les offsets à un offset spécifique et souhaité.
• --to-datetime <YYYY-MM-DDTHH:mm:SS.sss> : Réinitialise les offsets à l'offset correspondant à un horodatage spécifique.
• --shift-by <N> : Décale l'offset actuel de N positions (par exemple, -10 pour reculer de 10 messages, +10 pour avancer de 10 messages).

Fonctionnalités de sécurité cruciales : --dry-run et --execute

Effectuez toujours un --dry-run d'abord pour voir ce que l'opération de réinitialisation ferait avant de valider avec --execute.

Processus étape par étape pour la réinitialisation des offsets :

1. Arrêtez tous les consommateurs dans le groupe de consommateurs cible. Ceci est vital pour empêcher les consommateurs de valider de nouveaux offsets pendant que vous essayez de les réinitialiser.

2. Effectuez une simulation (dry run) pour prévisualiser les changements d'offset :

   • Exemple : Réinitialisation à l'offset le plus ancien (retraiter tous les messages)
     bash kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-consumer-app --reset-offsets --to-earliest --topic my-topic --dry-run

   • Exemple : Réinitialisation à l'offset le plus récent (sauter tous les messages en retard)
     bash kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-consumer-app --reset-offsets --to-latest --topic my-topic --dry-run

   • Exemple : Réinitialisation à un horodatage spécifique (par exemple, démarrer à partir du 2023-01-01 00:00:00 UTC)
     bash kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-consumer-app --reset-offsets --to-datetime 2023-01-01T00:00:00.000 --topic my-topic --dry-run

   • Exemple : Décalage des offsets en arrière de 500 messages (par partition)
     bash kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-consumer-app --reset-offsets --shift-by -500 --topic my-topic --dry-run

   La sortie de --dry-run montrera les changements d'offset proposés :
   GROUP TOPIC PARTITION NEW-OFFSET my-consumer-app my-topic 0 0 my-consumer-app my-topic 1 0

3. Exécutez la réinitialisation une fois que vous êtes satisfait des résultats de la simulation :

   • Exemple : Réinitialisation à l'offset le plus ancien (exécution)
     bash kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-consumer-app --reset-offsets --to-earliest --topic my-topic --execute

4. Redémarrez les applications consommatrices. Après la réinitialisation des offsets, redémarrez vos instances de consommateur. Elles commenceront alors à consommer à partir des nouveaux offsets de départ.

Astuce : Réinitialiser pour tous les topics d'un groupe

Si vous souhaitez réinitialiser les offsets pour tous les topics consommés par un groupe, vous pouvez omettre l'indicateur --topic lorsque vous utilisez kafka-consumer-groups.sh --reset-offsets. Soyez extrêmement prudent, car cela affecte tout.

Meilleures pratiques pour les opérations des consommateurs

• Surveillance proactive : Mettez en œuvre une surveillance robuste du décalage des consommateurs à l'aide d'outils comme Prometheus/Grafana, Datadog ou des scripts personnalisés. Configurez des alertes pour un décalage croissant rapidement ou constamment élevé.
• Comprendre l'idempotence : Concevez vos applications consommatrices pour qu'elles soient idempotentes. Cela permet un retraitement sécurisé des messages en cas de défaillance ou de réinitialisation des offsets.
• Ajuster max.poll.interval.ms : Ce paramètre définit le temps maximum pendant lequel un consommateur peut ne pas interroger (poll). Si votre logique de traitement est lente, augmentez cette valeur pour éviter les rééquilibrages indésirables, mais enquêtez également sur la lenteur sous-jacente.
• Gérer les messages non traitables : Mettez en œuvre une stratégie pour les messages « poison pill » (par exemple, les envoyer à une file d'attente de lettres mortes - Dead-Letter Queue - DLQ) plutôt que d'échouer et de bloquer le consommateur de manière répétée.
• Arrêts gracieux : Assurez-vous que vos applications consommatrices s'arrêtent correctement (gracieusement), validant leurs offsets finaux pour éviter un retraitement inutile ou des pics de décalage lors des redémarrages.
• Faire correspondre les partitions aux consommateurs : Pour un parallélisme optimal, visez à avoir au moins autant de partitions que vous prévoyez d'exécuter d'instances de consommateurs. Plus de partitions permettent plus de parallélisme.

Conclusion

Le décalage des consommateurs Kafka est un indicateur de santé critique pour toute pipeline de données en streaming. Un diagnostic et une résolution rapides des problèmes de décalage sont essentiels pour maintenir l'intégrité des données, l'efficacité du traitement et la fiabilité du système. En maîtrisant kafka-consumer-groups.sh, vous obtenez un puissant outil de ligne de commande pour inspecter l'état du groupe de consommateurs, identifier les partitions en retard et réinitialiser stratégiquement les offsets si nécessaire. N'oubliez pas de toujours donner la priorité à la compréhension de la cause profonde du décalage et d'utiliser les opérations de réinitialisation d'offset avec une extrême prudence, en tirant parti de --dry-run comme mesure de sécurité cruciale. La surveillance proactive et le respect des meilleures pratiques contribueront à garantir que vos consommateurs Kafka fonctionnent de manière fluide et efficace.