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

Guozhang Wang commented on KAFKA-6820:
--------------------------------------

John, thanks for the input. One thing I'm not clear is why you suggest we only 
expose methods for thread and processorNode level, but not other levels? Note 
that our current three-level hierarchy is:

1. Per-thread metrics, tags: {client.id -> thread-name}
2. Per-thread Per-task metrics, tags: {client.id -> thread-name, task-id -> 
task-id}
3a. Per-thread Per-task Per-Store metrics, tags: {client.id -> thread-name, 
task-id -> task-id, store-name -> store-name}
3b. Per-thread Per-task Per-ProcessorNode metrics, tags: {client.id -> 
thread-name, task-id -> task-id, processor-name -> processor-name}
3c. Per-thread Per-task Per-Cache metrics, tags: {client.id -> thread-name, 
task-id -> task-id, cache-name -> task-id-store-name}

Why don't we expose all these levels?


> 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)

Reply via email to