* 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: https://github.com/open-telemetry/opentelemetry-specification/issues/815
* Address PR comments
Co-authored-by: Bogdan Drutu <bogdandrutu@gmail.com>
* Extend attribute naming rules to metric labels
We earlier defined naming rules for attributes, however we do not have
similar rules for metric labels. This commit extends the exact same
set of rules to metric labels.
This was brought up in this comment https://github.com/open-telemetry/opentelemetry-specification/pull/807#discussion_r471550053
* Address PR comments
Fixes#454
Related to #3337
As the Messaging SIG merged its last OTEP 222, we will be adding operations
that require Links after Span creation, taking a direct route with `AddLink()`,
albeit without any of the new members suggested in #3337, e.g. `timestamp` (to be
discussed in a separate issue).
```
AddLink(spanContext, attributes /* optional */)
```
Based on discussion in semconv stability WG
Closes#3283
## Changes
Clarifies that attribute requirement levels apply to instrumentation.
And that, because users can transform their telemetry in a number of
ways (e.g. metric views, span processors, and collector
transformations), these requirement levels cannot be relied on by
telemetry consumers.
---------
Co-authored-by: Liudmila Molkova <limolkova@microsoft.com>
Co-authored-by: Bogdan Drutu <bogdandrutu@gmail.com>
* Describe how to handle converting non-string primitives for protocols that only support strings
* update wording to make clear that only non-string values are converted to strings
* unify language
* Update specification/common/common.md
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
Co-authored-by: Bogdan Drutu <bogdandrutu@gmail.com>
* Clarify that Trace/Meter are associated with Instrumentation Scope
This is a slightly different take on https://github.com/open-telemetry/opentelemetry-specification/issues/2203
Instead of renaming instrumentation library to instrumentation scope everywhere
this PR suggests targetted editing of wording of the Trace/Meter obtaining API
to allow not just instrumentation library but other instrumentation scopes to be
used as a parameter.
This change does not force renaming of API parameters and is not a breaking change.
We consider it a clarification of usage to match the intent that we had for the "name"
field.
If this PR is accepted there will be a follow up PR that will suggest to rename
InstrumentationLibrary* messages in OTLP proto to InstrumentationScope* message.
Such a change will not be a breaking change for the OTLP wire format and is acceptable.
If this PR is accepted we will also close https://github.com/open-telemetry/opentelemetry-specification/pull/1236
since it will be no longer necessary. The logger name will be recorded as the
instrumentation scope. This clarification will be a follow up PR that clarifies the
behavior in https://github.com/open-telemetry/oteps/blob/main/text/logs/0150-logging-library-sdk.md
* Prohibit usage of retired names in semantic conventions
This change adds a prohibition clause that requires that no old
metric or attribute name is used for a new attribute.
This is important to ensure reversibility of schema transformation
(converting from a new version to an old version of schema).
Without this restriction the following is possible:
Schema version 1. Attribute A exists.
Schema version 2. Attribute A is renamed to B. Appropriate schema file is created.
Schema version 3. Attribute A is introduced (a completely different new attribute).
Now attempting to go from Version 3 to version 1 is impossible since it requires
renaming B to A (for the change in version 2), but a different attribute A already exists.
* Fix based on comments
* Add changelog entry
Co-authored-by: Carlos Alberto Cortez <calberto.cortez@gmail.com>
* Provide a normative definition of Attribute (singular)
- Providing a normative definition of **attribute** (singular)
- Other copyedits
/cc @austinlparker @tedsuo
* Move anchor to make markdown checker happy
Resources are not susceptible to scenarios where excessive attributes
can be recorded unlike Spans. Resources are also immutable and it can be
hard for some SDKs to apply the limits at source at the time the
attributes are added to a resource. Furthermore, limits and Resources
both are generally defined and passed on to a TracerProvider which
forces a TracerProvider to either mutate the resource or generate a new
one with duplicate attributes in order to apply the limits to it.
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
Christian Neumüller