Support rocksdb metrics

[platinumhamburg]

Purpose

Linked issue: close #1320

Brief change log

Tests

API and Format

Documentation

[swuferhong]

Thanks @platinumhamburg. LGTM overall, I left one minor comment:

[platinumhamburg]

Thanks @platinumhamburg. LGTM overall, I left one minor comment:

@swuferhong Thank you for the detailed review comments; I've addressed all of them.

[swuferhong]

LGTM. Just one minor point to mention: we've already called removeTableBucketMetricsGroup in the stopReplica method—do we still need to call it in dropKv?

[platinumhamburg]

LGTM. Just one minor point to mention: we've already called removeTableBucketMetricsGroup in the stopReplica method—do we still need to call it in dropKv?

@swuferhong You are right, I removed it.

[wuchong]

Thanks, @platinumhamburg, for the contribution—this change looks good overall!

One concern I’d like to raise is that the lifecycle of RocksDBMetrics is currently decoupled from BucketMetricGroup, which leads to fragmented and inconsistent registration/unregistration logic. This is error-prone—for example, metrics might be forgotten, double-unregistered, or tied to the wrong scope.

Proposed Improvement

We should tighten the coupling between RocksDBMetrics and BucketMetricGroup, and remove its direct dependency on TabletServerMetricGroup.

1. Register RocksDB metrics alongside bucket creation

In org.apache.fluss.server.replica.Replica#initKvTablet (around L676), we can register the RocksDB metrics right after kvTablet is initialized, like this:

bucketMetricGroup
    .getTableMetricGroup()
    .registerRocksDBMetrics(tableBucket, kvTablet.getRocksDBMetrics());

This ensures metrics are registered once and only once, at the natural point of bucket initialization. It also eliminates the need to call TabletServerMetricGroup#registerRocksDBMetrics from multiple places which is a little hack that implicitly assumes the existence of a TableMetricGroup.

As a result, we can remove the method TabletServerMetricGroup#registerRocksDBMetrics entirely.

2. Simplify unregistration

Since RocksDBMetrics are tied with BucketMetricGroup, their cleanup is naturally handled when the bucket is removed—specifically, via TableMetricGroup#removeBucketMetricGroup(...), which already unregisters the associated metrics.

Therefore, we can safely remove:

• TabletServerMetricGroup#unregisterRocksDBMetrics
• TableMetricGroup#unregisterRocksDBMetrics

Let me know what you think!

[platinumhamburg]

BucketMetricGroup

@wuchong Thank you for your review comments. I’ll provide a detailed explanation of why I designed it this way. Initially, I decoupled RocksDB metrics from the bucket lifecycle for two main reasons:

We do not intend to collect, register, or report RocksDB monitoring metrics at the bucket granularity. Since BucketMetricGroup is specifically designed to manage bucket-level metrics, from a perspective of functional consistency, it was not appropriate to associate RocksDB metrics with BucketMetricGroup.

In practice, for primary key tables, the lifecycle of a KvTablet does not align with that of a bucket. The BucketMetricGroup is only unregistered when StopReplica is called, whereas the KvTablet must unregister its metric group as soon as it transitions to a follower role. Therefore, the lifecycle of KvTablet-related metrics should be tied to the KvTablet itself, not to the bucket.

[platinumhamburg]

@wuchong I'v resolved all review comments, thank for review again.