[
https://issues.apache.org/jira/browse/KAFKA-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16722623#comment-16722623
]
Guozhang Wang commented on KAFKA-6820:
--------------------------------------
[~NIzhikov]
Yes this ticket is still on, and actually it is a very good timing to ask :)
But I'd like to clearly define the scope of this ticket to separate it from
https://issues.apache.org/jira/browse/KAFKA-6819, this is based on discussions
with [~vvcephei] on those two ticket so far.
For KAFKA-6819: it should be for refactoring Stream's provided built-in
metrics, and as John suggested, we should consider only providing a single
granularity for each metric, and let the users to do rolling ups themselves
than letting Streams provides it. It would be a quite major built-in metrics
refactoring that requires a KIP, hence a big scope for discussion details.
For KAFKA-6820 (this ticket), let's scope on 2) in the description:
{code}
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.
{code}
I think KAFKA-6820 has a smaller scope and hence would be good to pick up for
now.
> 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)
