Kafka Basic Commands with Practical Examples

Intro

Kafka basic commands with practical examples should help operators move from an observed problem to a verified result. Start by identifying the installed version, deployment topology, prerequisites, and the exact component being inspected.

This article focuses on Kafka commands for developers, DevOps consultants, and technical startup teams. It connects Kafka basic commands, Kafka examples, Kafka cheat sheet, and Kafka operations to commands, expected output, failure signals, and recovery decisions that match the selected technology.

The goal is operational safety: observe before changing, limit the blast radius, use placeholders instead of secrets, verify the result, and document how to recover if the expected state is not reached.

Version and Environment Inventory

For Kafka commands, Version and Environment Inventory should name the relevant component, the supported version range, prerequisites, a read-only observation, the smallest justified change, and the command or signal that verifies the outcome.

Within Version and Environment Inventory, separate observation from intervention. Capture current state and timestamps first, protect credentials and private material, then change one scoped item only when its blast radius and recovery path are understood.

The important concepts for Version and Environment Inventory are Kafka commands, Kafka basic commands, Kafka examples, Kafka cheat sheet, and Kafka operations. Related areas such as NiFi, Apache Spark, and HDFS should be included only when they affect prerequisites, compatibility, security, observability, or recovery for this topic.

For Version and Environment Inventory, identify the installed version and deployment topology first. Capture the current observable state with a read-only command from the product's documented CLI or API, then define the expected result and failure signal before making a change.

Within Version and Environment Inventory, use version-appropriate commands from the official documentation. Examples should use explicit placeholders, state prerequisites and blast radius, and include a verification step plus a tested recovery path. Never place real credentials, tokens, private keys, or production identifiers in an article.

Checking Kafka Broker Version

Run the following command to get the broker version:

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

Expected output includes lines like localhost:9092 (id: 0 rack: null) -> ("api_key": 0, "min_version": 0, "max_version": 8). The exact version is often shown at the top or in the API versions. To get the full version including commit hash, use:

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

If the command fails with Could not connect to the server, verify that the broker is running and the advertised listeners are correct.

Checking Client Library Versions

For Java clients, run:

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

This prints the client version. Ensure the client version is compatible with the broker; Kafka generally maintains backward compatibility for clients within the same major version.

Topology Discovery

To list all brokers in the cluster, use:

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

It shows each broker ID and its advertised host. To see controller status:

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

In a KRaft cluster, this displays the controller and active nodes. For ZooKeeper-based clusters:

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

Expected: a list of broker IDs.

Safe Configuration Path

For Kafka commands, Safe Configuration Path should name the relevant component, the supported version range, prerequisites, a read-only observation, the smallest justified change, and the command or signal that verifies the outcome.

Within Safe Configuration Path, separate observation from intervention. Capture current state and timestamps first, protect credentials and private material, then change one scoped item only when its blast radius and recovery path are understood.

The important concepts for Safe Configuration Path are Kafka commands, Kafka basic commands, Kafka examples, Kafka cheat sheet, and Kafka operations. Related areas such as NiFi, Apache Spark, and HDFS should be included only when they affect prerequisites, compatibility, security, observability, or recovery for this topic.

For Safe Configuration Path, identify the installed version and deployment topology first. Capture the current observable state with a read-only command from the product's documented CLI or API, then define the expected result and failure signal before making a change.

Within Safe Configuration Path, use version-appropriate commands from the official documentation. Examples should use explicit placeholders, state prerequisites and blast radius, and include a verification step plus a tested recovery path. Never place real credentials, tokens, private keys, or production identifiers in an article.

Modifying Broker Configuration

To change a broker configuration dynamically, use kafka-configs.sh. For example, to set unclean.leader.election.enable to false on broker 0:

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

Verify with:

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

Expected output shows the updated configuration with unclean.leader.election.enable=false. To revert, set it back to the original value:

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

Topic Configuration Changes

Alter topic configuration, e.g., set retention.ms to 86400000 (1 day):

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

Verify:

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

Check for the line retention.ms=86400000 sensitive=false. If you need to revert, use the same command with the old value.

Verification and Diagnostics

For Kafka commands, Verification and Diagnostics should name the relevant component, the supported version range, prerequisites, a read-only observation, the smallest justified change, and the command or signal that verifies the outcome.

Within Verification and Diagnostics, separate observation from intervention. Capture current state and timestamps first, protect credentials and private material, then change one scoped item only when its blast radius and recovery path are understood.

The important concepts for Verification and Diagnostics are Kafka commands, Kafka basic commands, Kafka examples, Kafka cheat sheet, and Kafka operations. Related areas such as NiFi, Apache Spark, and HDFS should be included only when they affect prerequisites, compatibility, security, observability, or recovery for this topic.

For Verification and Diagnostics, identify the installed version and deployment topology first. Capture the current observable state with a read-only command from the product's documented CLI or API, then define the expected result and failure signal before making a change.

Within Verification and Diagnostics, use version-appropriate commands from the official documentation. Examples should use explicit placeholders, state prerequisites and blast radius, and include a verification step plus a tested recovery path. Never place real credentials, tokens, private keys, or production identifiers in an article.

Cluster Health Checks

Check cluster health with:

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

If all brokers respond, the cluster is reachable. To see under-replicated partitions:

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

Expected output: a list of under-replicated partitions or empty if healthy. In an unhealthy state, mark down the partition and broker IDs.

Consumer Group Lag

To check consumer group lag:

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

Output includes CURRENT-OFFSET, LOG-END-OFFSET, LAG. A lag greater than 0 for an extended period may indicate slow processing. To reset offsets (after stopping the consumer), use:

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

Verify by describing the group again; lag should be 0 or near 0.

Failure Modes and Recovery

For Kafka commands, Failure Modes and Recovery should name the relevant component, the supported version range, prerequisites, a read-only observation, the smallest justified change, and the command or signal that verifies the outcome.

Within Failure Modes and Recovery, separate observation from intervention. Capture current state and timestamps first, protect credentials and private material, then change one scoped item only when its blast radius and recovery path are understood.

The important concepts for Failure Modes and Recovery are Kafka commands, Kafka basic commands, Kafka examples, Kafka cheat sheet, and Kafka operations. Related areas such as NiFi, Apache Spark, and HDFS should be included only when they affect prerequisites, compatibility, security, observability, or recovery for this topic.

For Failure Modes and Recovery, identify the installed version and deployment topology first. Capture the current observable state with a read-only command from the product's documented CLI or API, then define the expected result and failure signal before making a change.

Within Failure Modes and Recovery, use version-appropriate commands from the official documentation. Examples should use explicit placeholders, state prerequisites and blast radius, and include a verification step plus a tested recovery path. Never place real credentials, tokens, private keys, or production identifiers in an article.

Reassigning Partitions

If a broker is overloaded or down, reassign partitions using kafka-reassign-partitions.sh. First, generate a reassignment JSON. For example, to move partitions from broker 0 to brokers 1 and 2:

Create a topics-to-move.json:

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

Generate the assignment:

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

This produces a proposed assignment. Save it to reassignment.json and execute:

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

Monitor progress:

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

Once verified, the reassignment is complete. If a failure occurs, check broker logs and ensure brokers are healthy before retrying.

Handling Under-Replicated Partitions

If under-replicated partitions persist, check the replication factor and broker status. Use:

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

Then identify the offline brokers. Bring them back online or increase replication factor via reassignment as above. For temporary relief, you can disable unclean leader election (if enabled) to prevent data loss, but the root cause must be addressed.

Operations Checklist

For Kafka commands, Operations Checklist should name the relevant component, the supported version range, prerequisites, a read-only observation, the smallest justified change, and the command or signal that verifies the outcome.

Within Operations Checklist, separate observation from intervention. Capture current state and timestamps first, protect credentials and private material, then change one scoped item only when its blast radius and recovery path are understood.

The important concepts for Operations Checklist are Kafka commands, Kafka basic commands, Kafka examples, Kafka cheat sheet, and Kafka operations. Related areas such as NiFi, Apache Spark, and HDFS should be included only when they affect prerequisites, compatibility, security, observability, or recovery for this topic.

For Operations Checklist, identify the installed version and deployment topology first. Capture the current observable state with a read-only command from the product's documented CLI or API, then define the expected result and failure signal before making a change.

Within Operations Checklist, use version-appropriate commands from the official documentation. Examples should use explicit placeholders, state prerequisites and blast radius, and include a verification step plus a tested recovery path. Never place real credentials, tokens, private keys, or production identifiers in an article.

Pre-Change Checklist

Before any change:

• Identify the component and version: run kafka-broker-api-versions.sh --bootstrap-server localhost:9092.
• Record current state: for topic configs, run kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-topic --describe and save output.
• Define expected result and failure signal explicitly.
• Assess blast radius: which consumers/producers are affected?
• Have a rollback plan: e.g., revert config change with kafka-configs.sh --alter using old value.

Common Commands Quick Reference

Conclusion

Kafka basic commands with practical examples is useful only when each recommendation is version-scoped, observable, and reversible where the technology permits. Copying a command without checking prerequisites and expected output is not an operations procedure.

As a next step, choose one low-risk verification for Kafka commands, record the current state, run the documented check, compare the result with the expected signal, and review dependencies such as NiFi, Apache Spark, and HDFS.

A reliable technical workflow makes failure visible, protects sensitive values, limits changes to the intended resource, and defines recovery verification before an incident forces the decision.