monedula-metrics-reporter

为什么

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 指标非得这么麻烦吗？。

配置

把 shadow jar 放入 $KAFKA_HOME/libs/，然后在 server.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 那一套搁置不用。