Commandes Kafka de base avec exemples pratiques

Introduction

Les commandes Kafka de base avec des exemples pratiques devraient aider les opérateurs à passer d'un problème observé à un résultat vérifié. Commencez par identifier la version installée, la topologie de déploiement, les prérequis et le composant exact inspecté.

Cet article se concentre sur les commandes Kafka pour les développeurs, les consultants DevOps et les équipes techniques de startups. Il relie les commandes Kafka de base, les exemples Kafka, l'aide-mémoire Kafka et les opérations Kafka aux commandes, aux sorties attendues, aux signaux d'échec et aux décisions de récupération qui correspondent à la technologie sélectionnée.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint.

Inventaire de la version et de l'environnement

Pour les commandes Kafka, l'inventaire de la version et de l'environnement doit nommer le composant concerné, la plage de versions prise en charge, les prérequis, une observation en lecture seule, le plus petit changement justifié et la commande ou le signal qui vérifie le résultat.

Dans l'inventaire de la version et de l'environnement, séparez l'observation de l'intervention. Capturez d'abord l'état actuel et les horodatages, protégez les informations d'identification et le matériel privé, puis modifiez un seul élément délimité uniquement lorsque son rayon d'impact et son chemin de récupération sont compris.

Les concepts importants pour l'inventaire de la version et de l'environnement sont les commandes Kafka, les commandes Kafka de base, les exemples Kafka, l'aide-mémoire Kafka et les opérations Kafka. Les domaines connexes tels que NiFi, Apache Spark et HDFS ne doivent être inclus que lorsqu'ils affectent les prérequis, la compatibilité, la sécurité, l'observabilité ou la récupération pour ce sujet.

Pour l'inventaire de la version et de l'environnement, identifiez d'abord la version installée et la topologie de déploiement. Capturez l'état observable actuel avec une commande en lecture seule de la CLI ou de l'API documentée du produit, puis définissez le résultat attendu et le signal d'échec avant d'apporter une modification.

Dans l'inventaire de la version et de l'environnement, utilisez des commandes adaptées à la version provenant de la documentation officielle. Les exemples doivent utiliser des espaces réservés explicites, indiquer les prérequis et le rayon d'impact, et inclure une étape de vérification ainsi qu'un chemin de récupération testé. Ne placez jamais de véritables informations d'identification, jetons, clés privées ou identifiants de production dans un article.

Vérification de la version du broker Kafka

Exécutez la commande suivante pour obtenir la version du broker :

kafka-broker-api-versions.sh --bootstrap-server localhost:9092

La sortie attendue comprend des lignes telles que localhost:9092 (id: 0 rack: null) -> ("api_key": 0, "min_version": 0, "max_version": 8). La version exacte est souvent affichée en haut ou dans les versions d'API. Pour obtenir la version complète incluant le hachage de commit, utilisez :

kafka-broker-api-versions.sh --bootstrap-server localhost:9092 | grep -i "version"

Si la commande échoue avec Could not connect to the server, vérifiez que le broker est en cours d'exécution et que les auditeurs annoncés sont corrects.

Vérification des versions des bibliothèques clientes

Pour les clients Java, exécutez :

java -cp "kafka-clients-*.jar" org.apache.kafka.clients.admin.AdminClient --version

Cela affiche la version du client. Assurez-vous que la version du client est compatible avec le broker ; Kafka maintient généralement une compatibilité ascendante pour les clients au sein de la même version majeure.

Découverte de la topologie

Pour lister tous les brokers du cluster, utilisez :

kafka-broker-api-versions.sh --bootstrap-server localhost:9092

Cela affiche chaque ID de broker et son hôte annoncé. Pour voir l'état du contrôleur :

kafka-metadata-quorum.sh --bootstrap-server localhost:9092 describe --status

Dans un cluster KRaft, cela affiche le contrôleur et les nœuds actifs. Pour les clusters basés sur ZooKeeper :

zookeeper-shell.sh localhost:2181 ls /brokers/ids

Résultat attendu : une liste d'identifiants de brokers.

Chemin de configuration sécurisé

Pour les commandes Kafka, le chemin de configuration sécurisé doit nommer le composant concerné, la plage de versions prise en charge, les prérequis, une observation en lecture seule, le plus petit changement justifié et la commande ou le signal qui vérifie le résultat.

Dans le chemin de configuration sécurisé, séparez l'observation de l'intervention. Capturez d'abord l'état actuel et les horodatages, protégez les informations d'identification et le matériel privé, puis modifiez un seul élément délimité uniquement lorsque son rayon d'impact et son chemin de récupération sont compris.

Les concepts importants pour le chemin de configuration sécurisé sont les commandes Kafka, les commandes Kafka de base, les exemples Kafka, l'aide-mémoire Kafka et les opérations Kafka. Les domaines connexes tels que NiFi, Apache Spark et HDFS ne doivent être inclus que lorsqu'ils affectent les prérequis, la compatibilité, la sécurité, l'observabilité ou la récupération pour ce sujet.

Pour le chemin de configuration sécurisé, identifiez d'abord la version installée et la topologie de déploiement. Capturez l'état observable actuel avec une commande en lecture seule de la CLI ou de l'API documentée du produit, puis définissez le résultat attendu et le signal d'échec avant d'apporter une modification.

Dans le chemin de configuration sécurisé, utilisez des commandes adaptées à la version provenant de la documentation officielle. Les exemples doivent utiliser des espaces réservés explicites, indiquer les prérequis et le rayon d'impact, et inclure une étape de vérification ainsi qu'un chemin de récupération testé. Ne placez jamais de véritables informations d'identification, jetons, clés privées ou identifiants de production dans un article.

Modification de la configuration du broker

Pour modifier dynamiquement une configuration de broker, utilisez kafka-configs.sh. Par exemple, pour définir unclean.leader.election.enable à false sur le broker 0 :

kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --add-config unclean.leader.election.enable=false

Vérifiez avec :

kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --describe

La sortie attendue affiche la configuration mise à jour avec unclean.leader.election.enable=false. Pour revenir en arrière, réinitialisez à la valeur d'origine :

kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --add-config unclean.leader.election.enable=true

Changements de configuration de sujet

Modifiez la configuration d'un sujet, par exemple définissez retention.ms à 86400000 (1 jour) :

kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-topic --alter --add-config retention.ms=86400000

Vérifiez :

kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-topic --describe

Recherchez la ligne retention.ms=86400000 sensitive=false. Si vous devez revenir en arrière, utilisez la même commande avec l'ancienne valeur.

Vérification et diagnostics

Pour les commandes Kafka, la vérification et les diagnostics doivent nommer le composant concerné, la plage de versions prise en charge, les prérequis, une observation en lecture seule, le plus petit changement justifié et la commande ou le signal qui vérifie le résultat.

Dans la vérification et les diagnostics, séparez l'observation de l'intervention. Capturez d'abord l'état actuel et les horodatages, protégez les informations d'identification et le matériel privé, puis modifiez un seul élément délimité uniquement lorsque son rayon d'impact et son chemin de récupération sont compris.

Les concepts importants pour la vérification et les diagnostics sont les commandes Kafka, les commandes Kafka de base, les exemples Kafka, l'aide-mémoire Kafka et les opérations Kafka. Les domaines connexes tels que NiFi, Apache Spark et HDFS ne doivent être inclus que lorsqu'ils affectent les prérequis, la compatibilité, la sécurité, l'observabilité ou la récupération pour ce sujet.

Pour la vérification et les diagnostics, identifiez d'abord la version installée et la topologie de déploiement. Capturez l'état observable actuel avec une commande en lecture seule de la CLI ou de l'API documentée du produit, puis définissez le résultat attendu et le signal d'échec avant d'apporter une modification.

Dans la vérification et les diagnostics, utilisez des commandes adaptées à la version provenant de la documentation officielle. Les exemples doivent utiliser des espaces réservés explicites, indiquer les prérequis et le rayon d'impact, et inclure une étape de vérification ainsi qu'un chemin de récupération testé. Ne placez jamais de véritables informations d'identification, jetons, clés privées ou identifiants de production dans un article.

Vérifications de l'état du cluster

Vérifiez l'état du cluster avec :

kafka-broker-api-versions.sh --bootstrap-server localhost:9092

Si tous les brokers répondent, le cluster est joignable. Pour voir les partitions sous-répliquées :

kafka-topics.sh --bootstrap-server localhost:9092 --describe --under-replicated-partitions

Sortie attendue : une liste des partitions sous-répliquées ou vide si le cluster est sain. En cas d'état dégradé, notez les identifiants des partitions et des brokers.

Retard du groupe de consommateurs

Pour vérifier le retard d'un groupe de consommateurs :

kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group my-group

La sortie inclut CURRENT-OFFSET, LOG-END-OFFSET, LAG. Un retard supérieur à 0 pendant une période prolongée peut indiquer un traitement lent. Pour réinitialiser les offsets (après avoir arrêté le consommateur), utilisez :

kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-group --reset-offsets --to-latest --execute --topic my-topic

Vérifiez en décrivant à nouveau le groupe ; le retard devrait être de 0 ou proche de 0.

Modes de défaillance et récupération

Pour les commandes Kafka, les modes de défaillance et la récupération doivent nommer le composant concerné, la plage de versions prise en charge, les prérequis, une observation en lecture seule, le plus petit changement justifié et la commande ou le signal qui vérifie le résultat.

Dans les modes de défaillance et la récupération, séparez l'observation de l'intervention. Capturez d'abord l'état actuel et les horodatages, protégez les informations d'identification et le matériel privé, puis modifiez un seul élément délimité uniquement lorsque son rayon d'impact et son chemin de récupération sont compris.

Les concepts importants pour les modes de défaillance et la récupération sont les commandes Kafka, les commandes Kafka de base, les exemples Kafka, l'aide-mémoire Kafka et les opérations Kafka. Les domaines connexes tels que NiFi, Apache Spark et HDFS ne doivent être inclus que lorsqu'ils affectent les prérequis, la compatibilité, la sécurité, l'observabilité ou la récupération pour ce sujet.

Pour les modes de défaillance et la récupération, identifiez d'abord la version installée et la topologie de déploiement. Capturez l'état observable actuel avec une commande en lecture seule de la CLI ou de l'API documentée du produit, puis définissez le résultat attendu et le signal d'échec avant d'apporter une modification.

Dans les modes de défaillance et la récupération, utilisez des commandes adaptées à la version provenant de la documentation officielle. Les exemples doivent utiliser des espaces réservés explicites, indiquer les prérequis et le rayon d'impact, et inclure une étape de vérification ainsi qu'un chemin de récupération testé. Ne placez jamais de véritables informations d'identification, jetons, clés privées ou identifiants de production dans un article.

Réaffectation des partitions

Si un broker est surchargé ou en panne, réaffectez les partitions à l'aide de kafka-reassign-partitions.sh. Tout d'abord, générez un JSON de réaffectation. Par exemple, pour déplacer des partitions du broker 0 vers les brokers 1 et 2 :

Créez un fichier topics-to-move.json :

{"topics": [{"topic": "my-topic"}], "version": 1}

Générez l'affectation :

kafka-reassign-partitions.sh --bootstrap-server localhost:9092 --topics-to-move-json-file topics-to-move.json --broker-list "1,2" --generate

Cela produit une affectation proposée. Enregistrez-la dans reassignment.json et exécutez :

kafka-reassign-partitions.sh --bootstrap-server localhost:9092 --reassignment-json-file reassignment.json --execute

Surveillez la progression :

kafka-reassign-partitions.sh --bootstrap-server localhost:9092 --reassignment-json-file reassignment.json --verify

Une fois vérifiée, la réaffectation est terminée. En cas d'échec, consultez les journaux du broker et assurez-vous que les brokers sont sains avant de réessayer.

Gestion des partitions sous-répliquées

Si les partitions sous-répliquées persistent, vérifiez le facteur de réplication et l'état des brokers. Utilisez :

kafka-topics.sh --bootstrap-server localhost:9092 --describe --under-replicated-partitions

Identifiez ensuite les brokers hors ligne. Remettez-les en ligne ou augmentez le facteur de réplication via la réaffectation comme ci-dessus. Pour un soulagement temporaire, vous pouvez désactiver l'élection de leader impure (si elle est activée) pour éviter la perte de données, mais la cause profonde doit être traitée.

Liste de contrôle des opérations

Pour les commandes Kafka, la liste de contrôle des opérations doit nommer le composant concerné, la plage de versions prise en charge, les prérequis, une observation en lecture seule, le plus petit changement justifié et la commande ou le signal qui vérifie le résultat.

Dans la liste de contrôle des opérations, séparez l'observation de l'intervention. Capturez d'abord l'état actuel et les horodatages, protégez les informations d'identification et le matériel privé, puis modifiez un seul élément délimité uniquement lorsque son rayon d'impact et son chemin de récupération sont compris.

Les concepts importants pour la liste de contrôle des opérations sont les commandes Kafka, les commandes Kafka de base, les exemples Kafka, l'aide-mémoire Kafka et les opérations Kafka. Les domaines connexes tels que NiFi, Apache Spark et HDFS ne doivent être inclus que lorsqu'ils affectent les prérequis, la compatibilité, la sécurité, l'observabilité ou la récupération pour ce sujet.

Pour la liste de contrôle des opérations, identifiez d'abord la version installée et la topologie de déploiement. Capturez l'état observable actuel avec une commande en lecture seule de la CLI ou de l'API documentée du produit, puis définissez le résultat attendu et le signal d'échec avant d'apporter une modification.

Dans la liste de contrôle des opérations, utilisez des commandes adaptées à la version provenant de la documentation officielle. Les exemples doivent utiliser des espaces réservés explicites, indiquer les prérequis et le rayon d'impact, et inclure une étape de vérification ainsi qu'un chemin de récupération testé. Ne placez jamais de véritables informations d'identification, jetons, clés privées ou identifiants de production dans un article.

Liste de contrôle avant modification

Avant toute modification :

• Identifiez le composant et la version : exécutez kafka-broker-api-versions.sh --bootstrap-server localhost:9092.
• Enregistrez l'état actuel : pour les configurations de sujet, exécutez kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-topic --describe et enregistrez la sortie.
• Définissez explicitement le résultat attendu et le signal d'échec.
• Évaluez le rayon d'impact : quels consommateurs/producteurs sont affectés ?
• Ayez un plan de retour en arrière : par exemple, annulez le changement de configuration avec kafka-configs.sh --alter en utilisant l'ancienne valeur.

Référence rapide des commandes courantes

Conclusion

Les commandes Kafka de base avec des exemples pratiques ne sont utiles que si chaque recommandation est limitée à une version, observable et réversible lorsque la technologie le permet. Copier une commande sans vérifier les prérequis et la sortie attendue ne constitue pas une procédure d'exploitation.

Comme prochaine étape, choisissez une vérification à faible risque pour les commandes Kafka, enregistrez l'état actuel, exécutez la vérification documentée, comparez le résultat avec le signal attendu et passez en revue les dépendances telles que NiFi, Apache Spark et HDFS.

Un flux de travail technique fiable rend les défaillances visibles, protège les valeurs sensibles, limite les modifications à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision.