os/bluestore: Better readability of perf output

[aclamk]

Get rid of bluestore_ prefix for some stats.

This is basically followup on #41557

Checklist

• Tracker (select at least one)
  • References tracker ticket
  • Very recent bug; references commit where it was introduced
  • New feature (ticket optional)
  • Doc update (no ticket needed)
  • Code cleanup (no ticket needed)
• Component impact
  • Affects Dashboard, opened tracker ticket
  • Affects Orchestrator, opened tracker ticket
  • No impact that needs to be tracked
• Documentation (select at least one)
  • Updates relevant documentation
  • No doc update is appropriate
• Tests (select at least one)
  • Includes unit test(s)
  • Includes integration test(s)
  • Includes bug reproducer
  • No tests

Show available Jenkins commands

• jenkins retest this please
• jenkins test classic perf
• jenkins test crimson perf
• jenkins test signed
• jenkins test make check
• jenkins test make check arm64
• jenkins test submodules
• jenkins test dashboard
• jenkins test dashboard cephadm
• jenkins test api
• jenkins test docs
• jenkins render docs
• jenkins test ceph-volume all
• jenkins test ceph-volume tox

[ljflores]

LGTM

[epuertat]

I'd suggest not to do this. Please think of perfcounter names as external API contracts, so changing them may have direct impact to users (both external or internal, as the Prometheus exporter or the Grafana dashboards). Once added, IMHO they should remain immutable until deprecated.

There's this nick (only 4 letters though) param that might work for perfcounter short names instead. If there's a real need for shortening perfcounter names (I still find the hierarchical naming valuable for users: bluestore > onode > hit) we should discuss decoupling the (ideally immutable) internal names from human-readable labels, but I think the nick might well serve this purpose.

Thank you @ljflores for warning Dashboard about this change!

[epuertat]

@aclamk is this because these metrics are exported by mgr/prom as ceph_bluestore_bluestore_onode_....? If that's the case, I agree that there's an (cosmetic) issue there and we could fix it, but I'm not exactly sure where: here or in mgr/prometheus, where the duplication happens? Any thoughts?

[ljflores]

@aclamk @epuertat this PR was in one of Yuri's test batches, but I told Yuri to pause merging this one, as there is some discussion to resolve.

[yuriw]

This passed tests so pls merge at will when ready

[epuertat]

@aclamk @ljflores I checked all the mgr/prometheus and these 2 perf-counters are the only ones that exhibit this redundancy (I worried this might need a larger clean-up), so let's get this merged!

Since this is blocking #44294 and we have the ok from @yuriw, I'll proceed.