version flag to inspecting JAR files, JMX, and the broker API versions endpoint. category: apache-kafka-glossary
Knowing the exact Kafka version running on your cluster matters for compatibility, security patching, and reproducing bugs. There's no single command that answers "what version is everything?" because brokers, clients, and CLI tools each carry their own version and may differ during rolling upgrades. This guide covers the five reliable ways to find each one.
Quick Answer
If you just want the version of the Kafka binaries on a server:
kafka-topics.sh --version
# or
kafka-broker-api-versions.sh --bootstrap-server localhost:9092 --version
Both print the version of the local Kafka install (e.g., 3.7.0 (Commit:abcd1234)). That's the version of the tools, which usually matches the broker if you installed everything from the same tarball, but doesn't have to.
For the version actually running on the broker process, read on.
Method 1: --version Flag on Any Kafka CLI Tool
Every shipped script supports --version:
kafka-topics.sh --version
kafka-console-consumer.sh --version
kafka-configs.sh --version
This prints the version of the JARs in the install directory, not the version of the remote broker. Useful for confirming what's on the host you're SSH'd into.
Method 2: Inspect the Kafka JARs
If the CLI is not on your PATH, look at the filenames in the Kafka libs/ directory:
ls /opt/kafka/libs/ | grep '^kafka_'
# kafka_2.13-3.7.0.jar
The filename encodes both the Scala version (2.13) and the Kafka version (3.7.0). This is the most direct way to see what's installed on disk, and the one tip that always works even when Kafka isn't running.
On a running broker:
ps -ef | grep kafka.Kafka | grep -o 'kafka_[0-9.]*-[0-9.]*' | head -1
This pulls the version from the classpath of the running JVM, which is the version actually being executed.
Method 3: Kafka Broker Logs
When a broker starts, it logs its version in the very first lines of server.log:
INFO Kafka version: 3.7.0 (org.apache.kafka.common.utils.AppInfoParser)
INFO Kafka commitId: abcd1234567890ef (org.apache.kafka.common.utils.AppInfoParser)
grep "Kafka version" /var/log/kafka/server.log | head -1
This is the authoritative answer for a remote broker: it's what the running JVM reported when it started.
Method 4: kafka-broker-api-versions.sh Against a Live Cluster
To query a remote cluster without SSH'ing in:
kafka-broker-api-versions.sh --bootstrap-server broker1:9092
Output looks like:
broker1:9092 (id: 1 rack: us-east-1a) -> (
Produce(0): 0 to 10 [usable: 10],
Fetch(1): 0 to 15 [usable: 15],
...
)
The script doesn't print a friendly version string, but the supported API version ranges map directly to release versions. The Kafka Protocol Guide lists which API version was added in which release. If a broker exposes Fetch up to version 15, it's running Kafka 3.5 or later, for example.
This is the only method that works without local access to the brokers.
Method 5: JMX
Brokers expose their version through JMX as part of the kafka.server:type=app-info MBean:
echo 'get -b kafka.server:type=app-info Version' | java -jar jmxterm.jar -l localhost:9999 -n
Or in a Prometheus exporter:
kafka_server_app_info_version{version="3.7.0"} 1.0
This is useful if you're already scraping JMX for monitoring; you get version drift detection for free across the cluster.
Checking the Client Library Version
Producer and consumer client versions are independent of the broker version. From inside your application:
// Java client
System.out.println(AppInfoParser.getVersion());
# kafka-python
import kafka
print(kafka.__version__)
# confluent-kafka-python
from confluent_kafka import version, libversion
print(version()) # Python client version
print(libversion()) # Underlying librdkafka version
Mismatched client and broker versions usually work thanks to Kafka's protocol compatibility, but consumer features (KIP-848, transactional reads, etc.) require both sides to support them. Always check both.
During a Rolling Upgrade
The version reported by individual brokers can differ during a rolling upgrade. inter.broker.protocol.version and log.message.format.version pin the effective protocol regardless of what's installed:
kafka-configs.sh --bootstrap-server localhost:9092 \
--entity-type brokers --entity-default --describe \
| grep -E "(inter.broker.protocol|log.message.format)"
If those settings point to an older version, your cluster is operating at that protocol level even if the JARs are newer. This is by design: it's how you safely roll back.
Common Mistakes
- Trusting
kafka-topics.sh --versionfor the broker version. It reports the local CLI version, which can differ from the remote broker. - Ignoring
inter.broker.protocol.version. A 3.7 broker still speaks the protocol you pinned, not the latest one. - Mixing Scala versions. The first number in
kafka_2.13-3.7.0.jaris the Scala version. Don't confuse it with the Kafka version. - Assuming client and broker are the same. They're independent. A 2.6 producer talking to a 3.7 broker is fine but won't get newer features.
Monitoring Version Drift
When you run Kafka at any scale, fleet-wide version drift becomes a real problem: a broker that didn't get patched, a client library left behind, an old consumer group. Pulse tracks Kafka broker and client versions automatically and surfaces drift, security advisories, and recommended upgrade paths. Start a free trial to see the version map of your fleet.
Frequently Asked Questions
Q: How do I check the Kafka version without restarting the broker?
A: Use grep "Kafka version" /var/log/kafka/server.log to read the version from existing startup logs, or query JMX (kafka.server:type=app-info). Neither requires a restart.
Q: How do I check the Kafka version on Confluent Platform?
A: Confluent Platform versions don't match Apache Kafka versions. Run confluent version or check /etc/confluent/docker/version in containerized installs. The mapping (CP 7.x ↔ Kafka 3.x) is documented in Confluent's release notes.
Q: How do I check the Kafka version on AWS MSK?
A: In the MSK console, select your cluster - the version is on the cluster summary page. From the CLI: aws kafka describe-cluster --cluster-arn <arn> --query 'ClusterInfo.CurrentBrokerSoftwareInfo.KafkaVersion'.
Q: How do I check the Kafka version from a Python client?
A: For kafka-python, use kafka.__version__. For confluent-kafka-python, use confluent_kafka.version() for the Python wrapper and confluent_kafka.libversion() for the underlying librdkafka.
Q: Why does kafka-topics.sh --version show a different version than my broker logs?
A: They're independent: the CLI version is whatever you installed on the host running the command; the broker version is whatever's running on the broker JVM. They can drift, especially in containerized or managed environments where the CLI host and brokers are upgraded separately.
Q: How do I check which Kafka protocol version is in use?
A: Run kafka-configs.sh --describe --entity-type brokers --entity-default and look for inter.broker.protocol.version. That's the effective protocol regardless of which JARs are loaded.
