Compatibility

Requirements

The reporter needs Java 17 or newer in the broker or client JVM, Apache Kafka 3.7.0 to 4.3.0 on the broker or client, the range CI tested for 0.10.0, and a collector endpoint that accepts OTLP over gRPC or HTTP. Versions before 3.7 lack the ClientTelemetry interface from KIP-714 that the reporter implements, and are not tested.

Brokers and clients

The same JAR runs in both. What it exports depends on where it runs:

	Broker	Java client
Kafka SPI metrics	Yes, with the kafka_server_ prefix	Yes, with the kafka_producer_ or kafka_consumer_ prefix
Yammer metrics	Yes	No, clients have no Yammer registry
JVM runtime metrics	Yes	Yes
KIP-714 client telemetry	Received and forwarded	Not applicable
Broker identity labels	kafka_cluster_id, kafka_node_id or kafka_broker_id	No

KRaft brokers report kafka_node_id, ZooKeeper-mode brokers kafka_broker_id.

Versions tested in CI

For the 0.10.0 release, CI built the shadow JAR and ran the unit and integration tests on JDK 17 and 21 against Kafka 3.7.0, 3.9.0, 4.2.0 and 4.3.0, and an end-to-end test, with Kafka, an OpenTelemetry Collector and Prometheus, against Kafka 4.2.0. The main branch has since moved to the newer Kafka patch releases and added JDK 25, twelve combinations in all, with its end-to-end test against Kafka 4.2.1:

	Kafka 3.7.2	Kafka 3.9.2	Kafka 4.2.1	Kafka 4.3.1
JDK 17	Yes	Yes	Yes	Yes
JDK 21	Yes	Yes	Yes	Yes
JDK 25	Yes	Yes	Yes	Yes

KIP-714 clients

Client telemetry needs clients that push KIP-714 metrics. The Java client and librdkafka 2.5 or later push by default, because enable.metrics.push is on. Collect Kafka client metrics with KIP-714 lists which metrics each client library pushes.

Collectors and backends

Any collector with an OTLP receiver works; the reporter does not depend on a particular backend. The quickstart uses the OpenTelemetry Collector Contrib 0.152.0, Prometheus 3.11.3 and Grafana 13.0.1.

For Prometheus, the quickstart lets Prometheus scrape the collector’s prometheus exporter. Pulling keeps the # TYPE and # HELP metadata, so Prometheus reports gauges, counters and histograms with their real types. If Prometheus cannot reach the collector, you can use the prometheusremotewrite exporter instead, but metric types will likely show up as unknown: the collector’s remote-write 1.x metadata path is unreliable, and remote write 2.0 was still marked “in development” in collector 0.152.

Next to other plugins

Kafka uses a single ClientTelemetry receiver per broker; if another telemetry plugin is configured too, which one Kafka selects is undefined. The JAR relocates its OpenTelemetry, gRPC, OkHttp and protobuf classes to its own package, so other plugins and libraries on Kafka’s classpath, or in a client application, can use their own versions.