Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require that names and namespaces are one global space across all semantic convention areas #832

Conversation

tigrannajaryan
Copy link
Member

@tigrannajaryan tigrannajaryan commented Aug 19, 2020

We have semantic conventions for Resources, Spans and Metrics (in the future also Logs are expected).
It was not clear if the attribute names across all convention areas should be globally unique.

This commit asserts that conventions are one space, they are not independent spaces with
their own namespaces each.

We prohibit using the same Span or Resource attribute name or metric label name but give them
slightly different meanings or value sets.

Resolves: #815

This PR is stacked on top of #821
Ignore the commits from #821
Only review commit f4f9555

@tigrannajaryan tigrannajaryan requested review from a team and yurishkuro August 19, 2020 16:06
@tigrannajaryan tigrannajaryan added the area:semantic-conventions Related to semantic conventions label Aug 19, 2020
@arminru
Copy link
Member

arminru commented Aug 19, 2020

I suppose you wanted to reference #821 instead of #828.

specification/common/common.md Outdated Show resolved Hide resolved
@tigrannajaryan
Copy link
Member Author

I suppose you wanted to reference #821 instead of #828.

Thanks for the catch. Fixed.

@bogdandrutu
Copy link
Member

Please rebase @tigrannajaryan

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 or label key in the future.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with the overall uniqueness requirement, but the motivation for this paragraph is not clear to me. Why would it be bad to have a name service.instance? Yes, it clashes with the namespace of service.instance.id, but so what?

Copy link
Member Author

@tigrannajaryan tigrannajaryan Aug 19, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Often the namespaces represent "things". For example all attributes in k8s.pod.* namespace are about Kubernetes Pod. If we allow an attribute name that coincides with a namespace it appears that the value of the attribute describes the "thing". However, in this case why is it not just another attribute under that namespace? What would be a reasonable value for k8s.pod attribute that does not have a better name in the k8s.pod.* namespace?
I think if attributes like that existed it would be a source of confusion. Does service.instance attribute describe something about service (as a "thing") or something about service.instance (which is a different "thing")?

The requirement I added prevents this confusion. When attributes are used for "things" it is very clear which "thing" they are about, it is the "thing" denoted by their namespace (whereas if we allowed what you suggest it could be also the "thing" denoted by the parent namespace).

Tigran Najaryan added 2 commits August 19, 2020 14:36
…antic convention areas

We have semantic conventions for Resources, Spans and Metrics (in the future also Logs are expected).
It was not clear if the attribute names across all convention areas should be globally unique.

This commit asserts that conventions are one space, they are not independent spaces with
their own namespaces each.

We prohibit using the same Span or Resource attribute name or metric label name but give them
slightly different meanings or value sets.

Resolves: open-telemetry#815
@tigrannajaryan tigrannajaryan force-pushed the feature/tigran/unique-semantic-conv-area branch from da6923b to e05488a Compare August 19, 2020 18:37
@bogdandrutu bogdandrutu merged commit e599f77 into open-telemetry:master Aug 24, 2020
@tigrannajaryan tigrannajaryan deleted the feature/tigran/unique-semantic-conv-area branch August 25, 2020 14:54
carlosalberto pushed a commit to carlosalberto/opentelemetry-specification that referenced this pull request Oct 31, 2024
…antic convention areas (open-telemetry#832)

* Require that names and namespaces are one global space across all semantic convention areas

We have semantic conventions for Resources, Spans and Metrics (in the future also Logs are expected).
It was not clear if the attribute names across all convention areas should be globally unique.

This commit asserts that conventions are one space, they are not independent spaces with
their own namespaces each.

We prohibit using the same Span or Resource attribute name or metric label name but give them
slightly different meanings or value sets.

Resolves: open-telemetry#815

* Address PR comments

Co-authored-by: Bogdan Drutu <bogdandrutu@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:semantic-conventions Related to semantic conventions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Decide if semantic conventions require that attribute names across all areas should be unique
6 participants