Metrics API usability: metric name normalization

[jonatan-ivanov]

Naming normalization is missing from the API user point of view - even guidance is missing (snake_case, camelCase, dot.case). Different metrics backends have different conventions for naming that they expect. How can we provide those if the user input is not normalized?

We touched this topic on the Metrics Workshop a little, and several people expressed some of their opinions, let me cc a few of them:
@shakuzen @ebullient @brian-brazil @bogdandrutu @jmacd @RichiH @matthiasr

[evankanderson]

Having an answer would be great here, though I think dot.case should be used for separating component levels, e.g. event.delivery but not target.replicas if "target replicas" is a single concept.

[ebullient]

Semantic conventions (for metrics names) are currently defined/proposed using dots: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/metrics/semantic_conventions/http-metrics.md .. there is one underscore there that I question as a transition to prometheus exposition formation would change all of those from . to _, eliminating the distinction.

Micrometer recommends consistent usage of dots for metric names. It then transforms those names into whatever conventions the backend expects. This is what is being asked here: what should be the convention for naming that API consumers use in their apps/libraries when creating/naming their metrics? You want consuming code to remain consistent, regardless of what exporters are used later.

[victlu]

I entered an issue here: #1366

1. What does it mean if multiple instrument register the same metric name?
2. How does instrument types scope in with metric name?
3. Does measure-number-type (i.e. int64, double, etc) play any part in differentiating metric names?