[ https://issues.apache.org/jira/browse/KAFKA-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452980#comment-16452980 ]
Guozhang Wang commented on KAFKA-6820: -------------------------------------- Thanks for your inputs. I agree that both the 2) and 3).a/c are not user facing concepts, while we also publicly document their metrics in the web docs. Thinking about your arguments, I was leaning towards only exposing 2) and 3).a/b for now. The reason for exposing 3).a is that we may want to expose some built-in RocksDB metrics from Streams and we could leveraging on 3).a, and also for user customized store engine they may also want to add their own metrics through 3).a. One thing we need to document clearly though, is that for level 3) metrics they are going to be one set of metrics for each instance, not aggregated across the task / thread. > 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)