Por quê

O caminho usual para observabilidade do Kafka é um sidecar de JMX exporter — um processo extra por broker, com sua própria janela de coleta, seus próprios modos de falha e um modelo de métricas que não corresponde exatamente ao que o resto da stack fala.

O monedula-metrics-reporter remove o sidecar. Ele se conecta à própria interface MetricsReporter do Kafka e envia métricas diretamente para um collector do OpenTelemetry via OTLP — gRPC ou HTTP, você escolhe. O contexto do broker (cluster id, node id) é anexado como resource attributes, de modo que o mesmo fluxo de métricas funciona em todos os brokers sem configuração por host.

Todo o I/O de exportação acontece em uma thread daemon. Se o collector estiver lento ou fora do ar, nada chega às threads que o Kafka usa para servir o tráfego.

Para o contexto completo — os dois sistemas de métricas escondidos dentro do Kafka, por que dashboards do Grafana importados tão frequentemente mostram No Data, e como o OTLP nativo desfaz esse nó — leia As métricas do Kafka precisam mesmo ser tão difíceis?.

Configurar

Coloque o shadow jar em $KAFKA_HOME/libs/ e, no server.properties:

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

O mesmo plugin funciona nos clientes Kafka — registre-o via metric.reporters na configuração do producer ou do consumer e você obtém o fluxo correspondente do lado do cliente no mesmo collector.

Uma stack de demonstração completa (broker + collector + Prometheus + Grafana) fica em quickstart/ no repositório.

Compatibilidade

Kafka 3.x e 4.x. Java 17+. Tanto o moderno SPI MetricsReporter quanto o registro legado do Yammer estão conectados, de modo que você obtém cobertura das métricas que o Kafka emite hoje sem deixar as do Yammer de fora.