Kafka CLI Command Builder
The exact command for kcat,
kafka-topics.sh,
kafka-consumer-groups.sh and
kafka-configs.sh, including the librdkafka
property names that are not Kafka's.
command.sh
updates as you type Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Expecting Java client property names to work
kcat is built on librdkafka, which has its own names. max.poll.records and several others simply do not exist.
Instead:Use the librdkafka names. The overlap is partial and the differences are silent.
Omitting -e when consuming a finite set
Without it kcat waits for more messages forever, which in a script hangs the pipeline.
Instead:Add -e to exit at the end of the partition.
Using -X for a property that needs a prefix
Consumer and producer specific properties need the right prefix in some contexts, and a wrong one is accepted and ignored.
Instead:Check with -X list, which prints what librdkafka actually recognises.
kcat is a librdkafka client, and that is most of what goes wrong
The flags are the easy half. The half that costs an afternoon is that kcat does not read Kafka's configuration language, and half of a working client.properties transfers into it while the other half is silently ignored.
There is no sasl.jaas.config in librdkafka
The credential is two separate properties, sasl.username and sasl.password, passed with -X. There is no truststore either: librdkafka uses OpenSSL, so it is ssl.ca.location pointing at a PEM file, and a .jks there fails with an error about the file format. What makes this genuinely confusing is that security.protocol and sasl.mechanism do have the same names, so a config that half works looks like a credential problem rather than an ignored setting.
kcat -C -b broker:9093 -t orders \
-X security.protocol=SASL_SSL \
-X sasl.mechanism=SCRAM-SHA-512 \
-X sasl.username=app \
-X sasl.password="$KAFKA_PASSWORD" kcat's default partitioner is not Java's
librdkafka uses consistent-random CRC32 by default and the Java client uses murmur2, so the same key lands on a different partition depending on which produced it. Producing test data with kcat into a topic whose ordering matters will interleave it with the real records in a way that looks like a broker fault. Set -X partitioner=murmur2_random to match Java. The key to partition mapper on this site shows what each one gives for a key.
The config flag is different on every Java tool
kafka-topics.sh, kafka-configs.sh, kafka-acls.sh and kafka-consumer-groups.sh take --command-config. kafka-console-consumer.sh takes --consumer.config and kafka-console-producer.sh takes --producer.config. Passing the wrong one is accepted and ignored by some versions, and the tool then connects with no security at all and times out against a listener that will not talk to it. The error says nothing about the flag.
A reset does nothing without --execute, and that is the good news
kafka-consumer-groups.sh --reset-offsets requires either --dry-run or --execute, and with neither it prints its usage and exits, which reads as a broken command rather than as a safeguard. It also only works when the group has no active members: with a consumer still running it fails, and the message is about the group being active. --to-datetime takes an ISO-8601 string with no zone and reads it in the JVM's local time zone, which is the quietest way to land somewhere unintended.
Increasing partitions is not reversible and moves your keys
kafka-topics.sh --alter --partitions can only increase the count, and increasing it changes which partition a key hashes to. Every key produced after the change lands somewhere new, so per-key ordering is broken across the boundary and a compacted topic ends up with two live versions of the same key on different partitions. There is no way to reduce the count afterwards.
The password is never on the command line here
kcat commands read it from an environment variable, because a command line ends up in your shell history and in ps output for every process on the host. The Java tools read it from a properties file instead, and the client.properties generator on this site emits that file without a password in it either. Nothing on this page is sent anywhere: the command is built in your browser.