Improve Custom Metric Discoverability and Descriptions

Hi Farhan,

Thanks for sharing this. Improving custom metric discoverability and making their meaning clearer is very much aligned with what we hear from other users. Long, unclear metric names that require scripts or trial and error to decode are not ideal for day-to-day troubleshooting and dashboard building.

The capability you described (friendly metric names, inline descriptions, and a plugin-to-metric explorer UI with hover or tooltip help) would significantly improve the experience of working with both built-in and custom metrics. It also fits with the direction of standards like OpenTelemetry semantic conventions, which try to standardize names and descriptions for common technologies.

We would like to understand how you want this to work in practice. For known technologies and standard signals (for example HTTP, databases, messaging, common runtimes), would you prefer that we align closely with OpenTelemetry semantic conventions for naming and descriptions so things feel consistent across tools? And for other areas that are less standardized, how would you imagine friendly names and descriptions being defined? For example:

• Should users be able to define aliases and descriptions for any metric?

• Or should the focus be on system-provided friendly names for built-in metrics, with a lighter mechanism for entirely custom ones?

Any concrete examples (for example specific metrics that are hard to understand today) would help us design a metric explorer and tooltip model that really solves the pain you are seeing.

When you think about your own teams, where do people struggle more right now: finding the right metric at all, or understanding what an already selected metric actually represents?

Kind regards,
Paras Kampasi