[
https://issues.apache.org/jira/browse/KAFKA-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452941#comment-16452941
]
John Roesler commented on KAFKA-6820:
-------------------------------------
[~guozhang] I think we should expose all levels that are meaningful from an
external perspective, but no more.
Definitely, the Thread (1) and the ProcessorNode (3b) are meaningful concepts
to a user of Streams. Since folks can and do implement their own State Stores,
(3a) should also be exposed.
Is plugging in your own Cache part of the API? If (and only if) so, we should
include (3c).
Is Task a user-facing concept or just an internal detail? If (and only if) it's
user-facing, we should expose (2).
In other words, I agree we can expose all the levels, but I wanted to verify
that they all *should* be exposed.
> 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)
