[
https://issues.apache.org/jira/browse/KAFKA-17895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17896468#comment-17896468
]
Matthias J. Sax commented on KAFKA-17895:
-----------------------------------------
Thanks for clarification. - I have no objection to add a corresponding metric
for in-memory stores.
{quote}Ideally, metric name would be the same for both types of state stores.
{quote}
Not sure if that's possible in general. Store metrics are naturally very store
specific IMHO, and only a few might apply to all stores...
> Expose KeyValueStore's approximateNumEntries as a metric
> --------------------------------------------------------
>
> Key: KAFKA-17895
> URL: https://issues.apache.org/jira/browse/KAFKA-17895
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Affects Versions: 3.8.1
> Reporter: Clément MATHIEU
> Priority: Minor
> Labels: needs-kip
>
> Tracking the evolution of a state store's size is often useful.
>
> For example, we often use state store to persist pending work and set alert
> on maximum size because it means the process is falling behind.
> While KafkaStreams exposes many generic state store related or RocksDB
> specificif metrics; is does not expose KeyValueStore#approximateNumEntries
> which is a key information.
> Is it an oversight or was it a deliberate choice?
> I would be great if this metrics could be added. I assume that both in-memory
> & rocksdb implementation of approximateNumEntries are fast enought to be used
> in metrics.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
