Kafka Command Line Tools

Kafka ships with a set of command line tools inside the bin folder. These tools create topics, send test messages, read messages, and inspect consumer groups. Learners use them to see Kafka working within minutes, and administrators use them to diagnose live clusters. Think of them as the dashboard buttons of a car: simple, direct, and always available.

The Tool Workflow

The diagram below shows how three common tools connect to a broker.

 kafka-console-producer                 kafka-console-consumer
        |                                        ^
        | writes                                 | reads
        v                                        |
   +-------------------------------------------------+
   |        Kafka Broker  (topic: greetings)         |
   +-------------------------------------------------+
        ^
        | manages
 kafka-topics  /  kafka-configs  /  kafka-consumer-groups

All examples below assume a broker running at localhost:9092. Linux and macOS use the .sh scripts. Windows users find matching .bat files inside bin/windows.

Create a Topic

bin/kafka-topics.sh --create --topic greetings \
  --partitions 3 --replication-factor 1 \
  --bootstrap-server localhost:9092

The command builds a topic named greetings with three partitions. A replication factor of 1 suits a single-broker laptop setup. A three-broker cluster accepts a factor of 3.

List and Describe Topics

bin/kafka-topics.sh --list --bootstrap-server localhost:9092

bin/kafka-topics.sh --describe --topic greetings \
  --bootstrap-server localhost:9092

The list option prints every topic name. The describe option prints partition count, the leader broker of each partition, replicas, and in-sync replicas. Run describe first whenever a topic behaves strangely.

Send Messages

bin/kafka-console-producer.sh --topic greetings \
  --bootstrap-server localhost:9092
> hello
> welcome to kafka

Every line typed into the prompt becomes one message. Press Ctrl+C to stop the producer.

Add key support with two extra properties.

bin/kafka-console-producer.sh --topic greetings \
  --bootstrap-server localhost:9092 \
  --property parse.key=true --property key.separator=:
> user1:hello

Read Messages

bin/kafka-console-consumer.sh --topic greetings \
  --from-beginning --bootstrap-server localhost:9092

The from-beginning flag replays every stored message. Without it, the consumer shows only new arrivals. Add --property print.key=true to display keys beside values.

Inspect Consumer Groups

bin/kafka-consumer-groups.sh --describe --group billing-app \
  --bootstrap-server localhost:9092

The output lists each partition, the current offset of the group, the log end offset, and the lag. Lag equals the log end offset minus the current offset. A growing lag signals that consumers fall behind producers.

Change a Topic Setting

bin/kafka-configs.sh --alter --entity-type topics \
  --entity-name greetings --add-config retention.ms=86400000 \
  --bootstrap-server localhost:9092

This command sets retention to one day without restarting any broker.

Delete a Topic

bin/kafka-topics.sh --delete --topic greetings \
  --bootstrap-server localhost:9092

Deletion removes all data in the topic. Double-check the name before pressing Enter on a shared cluster.

Tool Cheat Sheet

Task	Tool
Create, list, describe, delete topics	kafka-topics.sh
Send test messages	kafka-console-producer.sh
Read messages	kafka-console-consumer.sh
Check lag and group members	kafka-consumer-groups.sh
Change settings	kafka-configs.sh

Practice Exercise

Open two terminal windows. Start a console consumer in the first window and a console producer in the second. Type five messages in the producer window and watch them appear in the consumer window. Stop the consumer, send three more messages, and restart the consumer with the group flag to see how offsets resume from the last read position.

Helpful Habits

Store the bootstrap address in a shell variable so every command stays short and consistent. Run describe before and after any change to confirm the result. Test destructive commands on a development cluster first, and keep a written list of the commands used during a production incident so the team can review them later. Version differences matter too: older releases used a ZooKeeper address instead of the bootstrap server option, so check the tool help with the --help flag when a command fails.