Resolving as won't fix for trunk at least (may be in 0.89fb). The items raised by Enis in the description are no longer apt given per-cf metrics were removed by
HBASE-6410 (in 0.96) – too expensive to calculate.
That said, let me respond to the original list since much of it still has merit and I am trying to address in our new per-1.0 context.
Make Per-cf and global block cache metrics naming consistent (hbase.regionserver.blockCacheHitCount vs hbase.RegionServerDynamicStatistics.tbl.usertable.cf.ycsb.bt.Data.fsBlockReadCacheHitCnt)
This change looks done though rather than hbase.regionserver.blockCacheHitCount we have hbase.regionserver.server.blockCacheHitCount (The mbean that hosts this metric is hbase.regionserver.server).
All blockcache metrics have a blockCache prefix in hadoop metrics2 (except 'blockCountHitPercent' which I'll fix).
Rename hbase.RegionServerDynamicStatistics.XXX -> hbase.regionserver.dyn.XXX
Rename dynamic metric names tbl.usertable.cf.ycsb.bt.Data.fsBlockReadCacheHitCnt -> tbl=usertable.cf=ycsb.bt=Data.at=scan.BlockCacheHitCount. Here at stands for access type, and can be scan or compaction.
For at=compaction, we probably do not need per-block type (Data, Index, ...) metric values, shall we aggregate them?
Not pertinent to trunk.
Shall we extend per-cf metrics into
HBASE-5533 (read/write latency histograms)?
Not pertinent anymore.
With slab cache, we may no longer have one global block cache. Shall we enable per-cache type metrics? This can imply renaming hbase.regionserver.blockCache => hbase.regionserver.lrublockcache, slabblockcache, etc.
We need this. Will file an issue.
Add a configuration for disabling per-cf metrics.
No longer pertinent since removal.