Add a metric for the size of current live KV data

[DCjanus]

What would you like to be added?

Add a Prometheus gauge that reports the logical size of the current live KV data, for example:

etcd_mvcc_current_kv_size_in_bytes

The value could be defined as the sum of len(key) + len(value) for the latest non-deleted version of every key. It should exclude historical revisions, tombstones, database fragmentation, and other backend storage overhead.

This would complement the existing metrics:

• etcd_mvcc_db_total_size_in_use_in_bytes, which includes live data, retained MVCC history, and backend overhead;
• etcd_mvcc_db_total_size_in_bytes, which reports physically allocated database size.

The metric should not introduce labels and would represent the local member's applied state. If maintaining an exact value would add significant startup, write, range-delete, or snapshot-restore overhead, an approximate value or an etcd_debugging metric would also be useful. I would appreciate guidance on which trade-off fits etcd's metrics policy.

Why is this needed?

We operate an etcd cluster whose workload is dominated by overwrites. It has two main write patterns: frequent overwrites of small keys and less frequent overwrites of large keys. Auto-compaction uses a fixed revision-retention window.

While the frequent small-key writes were present, most revisions in that window were small and database usage remained stable. After those writes stopped, the overall write rate decreased, but large-key revisions made up a greater share of the retained history. etcd_mvcc_db_total_size_in_use_in_bytes therefore continued to grow.

The existing metrics showed the growth, but could not distinguish growth in current application data from accumulated MVCC history. We had to analyze a snapshot to identify the cause.

A current-live-data metric would make this distinction directly observable and help operators evaluate whether their auto-compaction retention policy matches their workload. The existing etcd_debugging_mvcc_total_put_size_in_bytes does not provide this view because it accumulates all put payloads rather than tracking the latest value of each key.

[DCjanus]

If this metric fits etcd's metrics policy, one possible implementation would be to store the current value length in each in-memory keyIndex (the key itself is already stored there). Puts could update the total by the size delta, deletes could subtract the key and current value sizes, and startup or snapshot restore could rebuild it during the existing MVCC scan.

This should avoid additional backend reads on the write path or an extra restore pass, but it would add one int64 (8 bytes) per key to the in-memory index.

Would this direction be worth pursuing? If so, would that per-key memory overhead be acceptable, and should the metric start under etcd_debugging rather than etcd?