Por qué

El camino habitual para la observabilidad de Kafka es un sidecar de exportador JMX: un proceso extra por broker, con su propia ventana de scrape, sus propios modos de fallo y un modelo de métricas que no encaja del todo con lo que habla el resto del stack.

monedula-metrics-reporter elimina el sidecar. Se conecta a la propia interfaz MetricsReporter de Kafka y empuja las métricas directamente a un collector de OpenTelemetry por OTLP —gRPC o HTTP, tú decides—. El contexto del broker (id del clúster, id del nodo) se adjunta como atributos de recurso, de modo que el mismo flujo de métricas funciona en todos los brokers sin cableado por host.

Toda la E/S de exportación ocurre en un hilo daemon. Si el collector está lento o caído, nada llega a los hilos que Kafka usa para servir tráfico.

Para el contexto completo —los dos sistemas de métricas escondidos dentro de Kafka, por qué los dashboards de Grafana importados tan a menudo muestran No Data y cómo el OTLP nativo lo desenreda— lee ¿Las métricas de Kafka tienen que ser tan difíciles?.

Configurar

Coloca el shadow jar en $KAFKA_HOME/libs/, luego en server.properties:

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

El mismo plugin funciona en los clientes de Kafka: regístralo a través de metric.reporters en la configuración del producer o del consumer y obtendrás el flujo equivalente del lado del cliente hacia el mismo collector.

Un stack de demo completo (broker + collector + Prometheus + Grafana) está disponible en quickstart/ dentro del repositorio.

Compatibilidad

Kafka 3.x y 4.x. Java 17+. Tanto la moderna SPI MetricsReporter como el registro heredado de Yammer están conectados, así que obtienes cobertura de las métricas que Kafka emite hoy sin dejar las de Yammer fuera de la mesa.