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

Jeff Klukas commented on KAFKA-3753:
------------------------------------

I agree that {{size}} is a bit ambiguous. I'd expect many folks would recognize 
the analogy to Java's {{Map.size}}, but there's no reason we need to stick with 
that.

RocksDB has nice consistency in their naming of properties, where {{size}} 
refers to bytes and {{num-entries}} refers to a count.

The PR discussion also brings up the point that since we can only get an 
estimated count from RocksDB, the name of this method should indicate that the 
result is not necessarily exact.

I'd be happy to see this method called {{estimatedCount}}, 
{{estimatedNumEntries}}, {{approximateCount}}, or some other variant.

> Add size() to the StateStore interface for metrics reporting
> ------------------------------------------------------------
>
>                 Key: KAFKA-3753
>                 URL: https://issues.apache.org/jira/browse/KAFKA-3753
>             Project: Kafka
>          Issue Type: Improvement
>          Components: streams
>            Reporter: Jeff Klukas
>            Assignee: Guozhang Wang
>            Priority: Minor
>              Labels: api
>             Fix For: 0.10.1.0
>
>
> As a developer building a Kafka Streams application, I'd like to have 
> visibility into what's happening with my state stores. How can I know if a 
> particular store is growing large? How can I know if a particular store is 
> frequently needing to hit disk?
> I'm interested to know if there are existing mechanisms for extracting this 
> information or if other people have thoughts on how we might approach this.
> I can't think of a way to provide metrics generically, so each state store 
> implementation would likely need to handle this separately. Given that the 
> default RocksDBStore will likely be the most-used, it would be a first target 
> for adding metrics.
> I'd be interested in knowing the total number of entries in the store, the 
> total size on disk and in memory, rates of gets and puts, and hit/miss ratio 
> for the MemoryLRUCache. Some of these numbers are likely calculable through 
> the RocksDB API, others may simply not be accessible.
> Would there be value to the wider community in having state stores register 
> metrics?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to