Warum

Der übliche Weg für Kafka-Observability ist ein JMX-Exporter-Sidecar — ein zusätzlicher Prozess pro Broker, mit eigenem Scrape-Fenster, eigenen Fehlermodi und einem Metrikmodell, das nicht ganz zu dem passt, was der Rest des Stacks spricht.

monedula-metrics-reporter entfernt das Sidecar. Es klinkt sich in Kafkas eigenes MetricsReporter-Interface ein und pusht Metriken direkt an einen OpenTelemetry-Collector über OTLP — gRPC oder HTTP, Ihre Wahl. Der Broker- Kontext (Cluster-ID, Node-ID) wird als Resource-Attribute angehängt, sodass derselbe Metrik-Stream über Broker hinweg funktioniert, ohne Verdrahtung pro Host.

Alle Export-I/O laufen auf einem Daemon-Thread. Wenn der Collector langsam ist oder ausfällt, erreicht nichts die Threads, die Kafka zur Bedienung des Datenverkehrs verwendet.

Für den vollständigen Hintergrund — die zwei Metriksysteme, die sich in Kafka verstecken, warum importierte Grafana-Dashboards so oft No Data anzeigen und wie natives OTLP das entwirrt — lesen Sie Müssen Kafka-Metriken so schwierig sein?.

Konfigurieren

Legen Sie die Shadow-JAR in $KAFKA_HOME/libs/ ab, dann in server.properties:

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

Dasselbe Plugin funktioniert auf Kafka-Clients — registrieren Sie es über metric.reporters in der Producer- oder Consumer-Konfiguration, und Sie erhalten den passenden Client-seitigen Stream in denselben Collector.

Ein vollständiger Demo-Stack (Broker + Collector + Prometheus + Grafana) liegt unter quickstart/ im Repo.

Kompatibilität

Kafka 3.x und 4.x. Java 17+. Sowohl die moderne MetricsReporter-SPI als auch die Legacy-Yammer-Registry sind verdrahtet, sodass Sie Abdeckung der Metriken erhalten, die Kafka heute ausgibt, ohne die Yammer-Metriken auf der Strecke zu lassen.