Clarification: metric namespaces are allowed to be metric names

[trask]

Related to #3457 (comment)

Note that this is different from attribute namespaces which are not allowed to coincide with attribute names:

Names SHOULD NOT coincide with namespaces. For example if service.instance.id is an attribute name then it is no longer valid to have an attribute named service.instance because service.instance is already a namespace. Because of this rule be careful when choosing names: every existing name prohibits existence of an equally named namespace in the future, and vice versa: any existing namespace prohibits existence of an equally named attribute key in the future.

See alternative proposal (that metric namespaces ARE NOT allowed to be metric names) at #3476

Changes

Clarifies that metric namespaces are allowed to be metric names.

[reyang]

@trask heads up - most likely this PR will be closed, and we'll ask you to resubmit the PR in a new repo, please refer to #3474 (comment).

[pirgeo]

One big upside to this proposal as compared to #3476 is that allowing it for metrics enables us to drop .count suffixes in metric names without "polluting" the attribute key space (since it is okay to have the same namespace). This would help with Prometheus compatibility (#3457) as well as conciseness. Additionally, similar to @jack-berg's comment here (although that thread is unrelated): #3484 (comment), there might be a question about whether certain semantic conventions should be an UpDownCounter or a Gauge. The .count suffix makes it seem like it is always a counter, when it does not have to be (or the use-case would also make sense as a Gauge). Being able to drop the suffix would generally improve the flexibility of the OTel semantic conventions, in my opinion.

[joaopgrassi]

I'm also in favor of this for the many reasons others pointed in the discussions. I believe preventing "namespaces" to be metrics names themselves would be very limiting.

We anyway have to apply judgment and good sense, because making this explicit now, doesn't mean adding a metric such as process.runtime.jvm is allowed, even though it "complies" with the wording added here. But that's what the review process is for anyway :)

[jsuereth]

Please move this to https://github.com/open-telemetry/semantic-conventions

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[trask]

hey all, the @open-telemetry/technical-committee is reviewing this issue, and asked to create a summary of pros/cons. I have created open-telemetry/semantic-conventions#50 based on the comments here, please comment further over there if I missed anything, thx!