Dlaczego

Zwykła ścieżka do obserwowalności Kafki to sidecar z eksporterem JMX — dodatkowy proces na każdego brokera, z własnym oknem zbierania (scrape), własnymi trybami awarii i modelem metryk, który niezupełnie pasuje do tego, czym mówi reszta stosu.

monedula-metrics-reporter usuwa sidecar. Podłącza się do własnego interfejsu MetricsReporter Kafki i wypycha metryki bezpośrednio do collectora OpenTelemetry przez OTLP — gRPC lub HTTP, Twój wybór. Kontekst brokera (identyfikator klastra, identyfikator węzła) jest dołączany jako atrybuty zasobu, więc ten sam strumień metryk działa na różnych brokerach bez okablowania per host.

Całe I/O eksportu odbywa się na wątku demona. Jeśli collector jest wolny lub niedostępny, nic nie dociera do wątków, których Kafka używa do obsługi ruchu.

Pełne tło — dwa systemy metryk ukryte wewnątrz Kafki, dlaczego zaimportowane dashboardy Grafany tak często pokazują No Data i jak natywny OTLP to rozplątuje — przeczytasz w Czy metryki Kafki muszą być takie trudne?.

Konfiguracja

Wrzuć shadow jar do $KAFKA_HOME/libs/, a następnie w server.properties:

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

Ta sama wtyczka działa na klientach Kafki — zarejestruj ją przez metric.reporters w konfiguracji producenta lub konsumenta, a otrzymasz odpowiadający strumień po stronie klienta do tego samego collectora.

Kompletny stos demonstracyjny (broker + collector + Prometheus + Grafana) znajduje się w katalogu quickstart/ w repozytorium.

Zgodność

Kafka 3.x i 4.x. Java 17+. Podłączone są zarówno nowoczesne SPI MetricsReporter, jak i starszy rejestr Yammer, więc otrzymujesz pokrycie metryk emitowanych dziś przez Kafkę bez pozostawiania tych z Yammer poza zasięgiem.