[
https://issues.apache.org/jira/browse/KAFKA-17895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17893981#comment-17893981
]
A. Sophie Blee-Goldman commented on KAFKA-17895:
------------------------------------------------
My guess is that this wasn't exposed as a metric because it's only an
approximation and has no guarantee of being correct. For in-memory stores it's
probably going to be accurate but I have no idea how accurate the rocksdb
metric will be and would imagine it can be quite misleading. It's based on the
property estimate-num-keys if you want to do some research there.
That said, there's no reason not to expose this as a metric I suppose. We
accept KIPs if you'd like to pick this up this yourself!
> 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: Major
>
> 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)
