[jira] [Commented] (KAFKA-3711) Allow configuration of MetricsReporter subclasses

["Ewen Cheslack-Postava (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15311714#comment-15311714 ] 

Ewen Cheslack-Postava commented on KAFKA-3711:
----------------------------------------------

[~jeff.klukas@gmail.com] I'm pretty sure this is the intended behavior for {{MetricsReporter}} as this is how pretty much all other configs are passed through to these types of classes (serializer, deserializer, partitioner, etc). In theory we track which are used and which aren't -- we definitely track this within {{AbstractConfig}}, and then {{originals()}} returns a {{RecordingMap}} which tracks usage.

I think maybe the issue here is that we're passing {{this.originals}} directly to the other class in {{getConfiguredInstance}} and {{getConfiguredInstances}}. I think that would address the specific case you're seeing. However, we also found in Connect that we couldn't use this *exact* approach because we needed to sort of "namespace" subsets of configs due to conflicts (e.g. producer and consumer overrides in workers could potentially conflict). To fix that we may need to clean up a few other places that {{this.originals}} in {{AbstractConfig}} is used.

I'd love to see this fixed -- some of the config logging is quite annoying and misleading.

> Allow configuration of MetricsReporter subclasses
> -------------------------------------------------
>
>                 Key: KAFKA-3711
>                 URL: https://issues.apache.org/jira/browse/KAFKA-3711
>             Project: Kafka
>          Issue Type: Improvement
>          Components: clients, streams
>            Reporter: Jeff Klukas
>            Assignee: Guozhang Wang
>            Priority: Minor
>             Fix For: 0.10.1.0
>
>
> The current interface for attaching metrics reporters to clients allows only defining a list of class names, but provides no means for configuring those reporters.
> There is at least one existing project (https://github.com/apakulov/kafka-graphite) that solves this problem by passing additional properties into the client, which then get passed on to the reporter. This seems to work quite well, but it generates warnings like {{The configuration kafka.graphite.metrics.prefix = foo was supplied but isn't a known config.}}
> Should passing arbitrary additional parameters like this be officially supported as the way to configure metrics reporters? Should these warnings about unrecognized parameters be removed?
> Perhaps there should be some mechanism for registering additional configuration parameters for clients to expect?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)