Skip to content

Add conventions for attribute names #807

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

Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
88 changes: 87 additions & 1 deletion specification/common/common.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ Table of Contents
</summary>

- [Attributes](#attributes)

- [Attribute Naming](#attribute-naming)
</details>

## Attributes
Expand Down Expand Up @@ -36,3 +36,89 @@ This is required for map/dictionary structures represented as two arrays with
indices that are kept in sync (e.g., two attributes `header_keys` and `header_values`,
both containing an array of strings to represent a mapping
`header_keys[i] -> header_values[i]`).

### Attribute Naming

Attribute name (also known as the "attribute key") MUST be a valid Unicode
Copy link
Member

Choose a reason for hiding this comment

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

let's limit to printable characters and forbid control ones?

Copy link
Member

Choose a reason for hiding this comment

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

We are opening a different can of worms here, which is #504

Copy link
Member Author

Choose a reason for hiding this comment

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

@SergeyKanzhelev I wanted to place the minimal restrictions here, then refine them slightly differently in the 2 sub-sections below (and for semantic conventions the limitations are precisely as you listed - only printable ASCII characters). I can remove this sentence since it is somewhat superfluous given additional restrictions listed later in the document.

Copy link
Member Author

Choose a reason for hiding this comment

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

@Oberon00 I'd like to avoid addressing #504 in this same PR. They are related but don't need to be solved at the same time.

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, @tigrannajaryan. I think the restriction of being valid Unicode is OK for a start although maybe even that should be dropped from the PR to not get lost in that discussion.

sequence.

Attribute names SHOULD follow these rules:

- Use namespacing to avoid name clashes. Delimit the namespaces using a dot
character. For example `service.version` denotes the service version where
`service` is the namespace and `version` is an attribute in that namespace.

- Namespaces can be nested. For example `telemetry.sdk` is a namespace inside
top-level `telemetry` namespace and `telemetry.sdk.name` is an attribute
inside `telemetry.sdk` namespace.

- For each multi-word dot-delimited component of the attribute name separate the
words by underscores (i.e. use snake_case). For example `http.status_code`
denotes the status code in the http namespace.

- Attribute names SHOULD NOT coincide with namespaces. For example if
Copy link
Contributor

Choose a reason for hiding this comment

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

An example just came up which may describe this even more clearly. You can't have attribute service.version and a clarifying attribute service.version.type it needs to be something like service.version.id.

`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 attribute names:
every existing attribute name prohibits existence of an equally named
namespace in the future, and vice versa: any existing namespace prohibits
existence of an equally named attribute in the future.

#### Recommendations for OpenTelemetry Authors

- All attribute names that are part of OpenTelemetry semantic conventions
SHOULD be part of a namespace.

- When coming up with a new convention make sure to check existing namespaces
Copy link
Member

@Oberon00 Oberon00 Aug 14, 2020

Choose a reason for hiding this comment

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

Are keys supposed to be unique across all three of these? #739 (comment) seems to not adhere to this principle.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's a good question. I am inclined to say "yes", simply to avoid confusion that will arise if there are attibutes with the same name for a Resource and a Span which mean different things.

Copy link
Member Author

Choose a reason for hiding this comment

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

Created an issue #815

for
[Resources](https://github.com/open-telemetry/opentelemetry-specification/tree/master/specification/resource/semantic_conventions),
[Spans](https://github.com/open-telemetry/opentelemetry-specification/tree/master/specification/trace/semantic_conventions),
and
[Metrics](https://github.com/open-telemetry/opentelemetry-specification/tree/master/specification/metrics/semantic_conventions)
Copy link
Member

Choose a reason for hiding this comment

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

Maybe explicitly state somewhere that label keys are equivalent to attribute keys in the scope of this document.

Copy link
Member Author

Choose a reason for hiding this comment

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

Submitted #821

to see if the new attributes fits.

- When a new namespace is necessary consider whether it should be a top-level
namespace (e.g. `service`) or a nested namespace (e.g. `service.instance`).

- Semantic conventions MUST limit attribute names to printable Basic Latin
characters (more precisely to
[U+0021 .. U+007E](https://en.wikipedia.org/wiki/Basic_Latin_(Unicode_block)#Table_of_characters)
subset of Unicode code points). It is recommended to further limit attribute
names to the following Unicode code points: Latin alphabet, Numeric,
Underscore, Dot (as namespace delimiter).

#### Recommendations for Application Developers

As an application developer when you need to record an attribute first consult
existing semantic conventions for
[Resources](https://github.com/open-telemetry/opentelemetry-specification/tree/master/specification/resource/semantic_conventions),
[Spans](https://github.com/open-telemetry/opentelemetry-specification/tree/master/specification/trace/semantic_conventions),
and
[Metrics](https://github.com/open-telemetry/opentelemetry-specification/tree/master/specification/metrics/semantic_conventions).
If appropriate attribute name does not exists you will need to come up with a
new name. To do that consider a few options:

- The attribute is specific to your company and may be possibly used outside the
company as well. To avoid name clashes with attributes introduced by other
companies (in a distributed system that uses applications from multiple
vendors) it is recommended to prefix the attribute name by your company's
reverse domain name, e.g. `com.acme.shopname`.

- The attribute is specific to your application that will be used internally
only. If you already have an internal company process that helps you to ensure
no name clashes happen then feel free to follow it. Otherwise it is
recommended to prefix the attribute name by your application name, provided
that the application name is reasonably unique within your organization (e.g.
`myuniquemapapp.longitude` is likely fine). Make sure the application name
does not clash with an existing semantic convention namespace.

- The attribute may be generally applicable to applications in the industry. In
that case consider submitting a proposal to this specification to add a new
attribute to the semantic conventions, if necessary also to add a new
namespace for the attribute.

It is recommended to limit attribute names to printable Basic Latin characters
(more precisely to
[U+0021 .. U+007E](https://en.wikipedia.org/wiki/Basic_Latin_(Unicode_block)#Table_of_characters)
subset of Unicode code points).