---
title: "Report metrics from Java clients"
description: "Run the same reporter JAR inside Java producers and consumers, and what changes on clients, where there is no Yammer registry."
url: https://monedula.dev/flock/docs/metrics-reporter/how-to/report-client-metrics/
---
The JAR that runs on brokers also runs inside a Java producer or consumer, where it exports the client's Kafka SPI metrics and its JVM metrics over OTLP. To collect client metrics without changing the clients at all, use [KIP-714 client telemetry](/flock/docs/metrics-reporter/how-to/collect-client-telemetry/) through the brokers instead.

## Before you start

- A Java application on Java 17 or newer that uses the Kafka client 3.7.0 to 4.3.0; see [Compatibility](/flock/docs/metrics-reporter/concepts/compatibility/).
- The reporter JAR, from the same sources as for brokers: see [Install the reporter on brokers](/flock/docs/metrics-reporter/how-to/install-on-brokers/), step 1.
- An OpenTelemetry Collector with an OTLP receiver that the application can reach.

## Steps

### 1. Put the JAR on the application's classpath

Add `monedula-metrics-reporter-0.10.0.jar` to the classpath of the application that runs the producer or consumer, next to `kafka-clients`. Its relocated libraries do not clash with the application's own OpenTelemetry or gRPC libraries.

### 2. Add the reporter to the client configuration

Add the same lines as on a broker to the producer or consumer configuration:

```properties
# One reporter, both metric streams. On brokers it covers Kafka SPI *and* Yammer
# registries; on clients only the SPI registry is present and the Yammer side
# auto-disables.
metric.reporters=dev.monedula.metricsreporter.OtlpMetricReporter

otlp.metric.reporter.endpoint=http://otel-collector:4317
otlp.metric.reporter.transport=grpc
```

Every other `otlp.metric.reporter.*` key works on clients too; the [configuration keys](/flock/docs/metrics-reporter/reference/configuration/) reference lists them.

### 3. Turn off what the client does not need

- `otlp.metric.reporter.client.telemetry.enabled=false`: the KIP-714 receiver only does something on a broker. On a client it never receives anything, but with the default `true` the reporter still starts its forwarder and exports the five `monedula_reporter_clienttelemetry_*` metrics, which stay at zero.
- `otlp.metric.reporter.jvm.metrics.enabled=false`: if the application already exports its JVM metrics another way, so they are not sent twice.

### 4. Restart the application

The reporter starts with the producer or consumer, so restart the application to load it.

## What changes on a client

A client exports its Kafka SPI, JVM and self-monitoring metrics, and no Yammer metrics. Kafka sets the metrics namespace per process role, so SPI names start with `kafka_producer_` or `kafka_consumer_` instead of `kafka_server_`: a producer's `producer-metrics` group and `record-send-rate` metric become `kafka_producer_producer_metrics_record_send_rate`. Client series carry no `kafka_cluster_id` or `kafka_node_id`, and each reporter instance gets its own `service_instance_id`; [Metric names and labels](/flock/docs/metrics-reporter/concepts/metric-names-and-labels/) shows how to make it stable. As on a broker, a slow collector or a bad reporter setting does not hold up the producer or consumer ([Fail-safe by design](/flock/docs/metrics-reporter/concepts/fail-safe-design/)).

## Check it worked

One export interval after the application starts, 30 seconds by default, its series reach the collector. In Prometheus, look for metrics that start with `kafka_producer_` or `kafka_consumer_`, and for `monedula_reporter_export_success_total` with the application's `service_instance_id`. If the application's logs show `OtlpMetricReporter failed to initialize, running as no-op`, a reporter setting is invalid.