Hi Xavier, That's certainly an option, however it does not solve the problem for our users that still rely on JMX integration to collect metrics.
Absolutely. We already provide the ability to write reporter plugins via the MetricsReporter interface. And rather than building a separate HTTP interface, I think we should extend the MetricsReporter interface to also provide access to yammer metrics – not just Kafka metrics – since there is no clear effort to move away from Yammer at this time. This way one could build any kind of reporter – HTTP or otherwise – without having to rely on Kafka internal classes Yes, as you point it out it's important decouple the metric reporter from internal classes and for this exposing Yammer would be a good step. >From this perspective the REST API goes one step further as you won't have to ship the broker and the reporter plugin together. Anyway, don't want to derail the conversation here with the REST stuff (perhaps I'll open a KIP for that sometime and we can discuss it there :) ). Thanks, Viktor On Wed, Oct 30, 2019 at 10:44 PM Xavier Léauté <xav...@confluent.io> wrote: > > > > A follow-up question, maybe to list in the future work section as it's > > somewhat parallel to this KIP: have you thought about implementing a REST > > reporter for metrics? > > > That's certainly an option, however it does not solve the problem for our > users that still rely on JMX integration to collect metrics. > > We already provide the ability to write reporter plugins via the > MetricsReporter interface. > And rather than building a separate HTTP interface, I think we should > extend the MetricsReporter interface to also > provide access to yammer metrics – not just Kafka metrics – since there is > no clear effort to move away from Yammer at this time. > > This way one could build any kind of reporter – HTTP or otherwise – without > having to rely on Kafka internal classes >
