---
title: "monedula-metrics-reporter"
repo: https://github.com/monedula-dev/monedula-metrics-reporter
language: Java
license: AGPL-3.0
status: active
maintainers: ["grzegorz", "michal"]
---## 为什么

Kafka 可观测性的常规做法是部署一个 JMX exporter 边车——每个 broker 都要多跑一个进程，有它自己的抓取窗口、自己的故障模式，以及一套与技术栈其余部分不太一致的指标模型。

`monedula-metrics-reporter` 去掉了这个边车。它接入 Kafka 自身的 `MetricsReporter` 接口，通过 OTLP 直接把指标推送到 OpenTelemetry collector——gRPC 或 HTTP，由你选择。broker 上下文（cluster id、node id）会作为资源属性附加，因此同一条指标流在各个 broker 之间无需逐主机接线即可工作。

所有导出 I/O 都发生在一个守护线程上。如果 collector 缓慢或宕机，任何东西都不会触及 Kafka 用来处理流量的线程。

要了解完整背景——隐藏在 Kafka 内部的两套指标系统、为什么导入的 Grafana 仪表盘那么常显示 *No Data*，以及原生 OTLP 如何理清这一切——请阅读 [Kafka 指标非得这么麻烦吗？](/blog/kafka-metrics-opentelemetry-otlp-monedula-metrics-reporter/)。

## 配置

把 shadow jar 放入 `$KAFKA_HOME/libs/`，然后在 `server.properties` 中：

```properties
metric.reporters=dev.monedula.metricsreporter.OtlpMetricReporter
otlp.metric.reporter.endpoint=http://otel-collector:4317
otlp.metric.reporter.transport=grpc
```

同一个插件也能在 Kafka 客户端上工作——在 producer 或 consumer 配置中通过 `metric.reporters` 注册它，你就能把相应的客户端侧指标流送入同一个 collector。

仓库中的 `quickstart/` 目录下有一套完整的演示栈（broker + collector + Prometheus + Grafana）。

## 兼容性

Kafka 3.x 与 4.x。Java 17+。现代的 `MetricsReporter` SPI 与旧版 Yammer registry 都已接好，因此你能覆盖 Kafka 如今所发出的指标，而不必把 Yammer 那一套搁置不用。