[
https://issues.apache.org/jira/browse/KAFKA-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16450473#comment-16450473
]
John Roesler commented on KAFKA-6820:
-------------------------------------
I'm +1 on separating the built-in metrics from the methods we expose for public
use.
Right now, I'm of the opinion it would be nicer to just expose methods for
getting a sensor at the Thread and at the ProcessorNode level. The process of
adding metrics to a sensor is really not that bad, and we can provide
documentation to help with it.
This would allow users to measure exactly what they need to, without having to
create new feature requests.
Plus, it seems like they'd currently have to dig in to understand what the
latencyAndThroughputSensor is versus a throughPutSensor, just to decide which
one they need. This process includes learning what they would have needed to
learn to just add their own metrics, so I argue these convenience methods are
strictly more complicated to understand than raw sensors/metrics.
I think it would be even simpler if we just handed them the Metrics object, but
that would mean that users would have to manage unloading their sensors inside
Processor#close(), but this is only straightforward for ProcessorNode-level
metrics. To correctly unload higher-level metrics, they'd have to track the
number of children and unload the metric only when it has no more children.
Plus, it's too easy to introduce contention by creating a top-level metric
(it's both not obvious that this will introduce contention, and it's easy to do
it even if you didn't mean to).
For this reason, I think we should track user-created sensors at each level up
to the thread, which means we have to control their creation and not give a
direct reference to the Metrics registry.
> Improve on StreamsMetrics Public APIs
> -------------------------------------
>
> Key: KAFKA-6820
> URL: https://issues.apache.org/jira/browse/KAFKA-6820
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: Guozhang Wang
> Priority: Major
> Labels: needs-kip
>
> Our current `addLatencyAndThroughputSensor`, `addThroughputSensor` are not
> very well designed and hence not very user friendly to people to add their
> customized sensors. We could consider improving on this feature. Some related
> things to consider:
> 1. Our internal built-in metrics should be independent on these public APIs
> which are for user customized sensor only. See KAFKA-6819 for related
> description.
> 2. We could enforce the scopeName possible values, and well document on the
> sensor hierarchies that would be incurred from the function calls. In this
> way the library can help closing user's sensors automatically when the
> corresponding scope (store, task, thread, etc) is being de-constructed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
