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

[WIP] Define semantic convention group and mixed stability rules #1472

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft
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
83 changes: 83 additions & 0 deletions docs/general/group-stability.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,83 @@
<!--- Hugo front matter used to generate the website version of this page:
linkTitle: Semantic Convention Groups
aliases: [semantic-convention-groups]
--->

# Semantic Convention Groups

**Status**: [Experimental][DocumentStatus]

Spans, metrics, events, and resources are defined in semantic convention groups in YAML schema.
Each group has a `type` property that could be one of the following:

- `span` - defines semantic convention for a specific type of span, such as HTTP `CLIENT`
- `metric` - defines semantic convention for a specific metric, such as HTTP client request duration
- `event` - defines semantic conventions for a specific event, such as exception.
- `resource` - defines semantic conventions for a specific entity the telemetry is collected within,
such as `service`.

Groups that have `attribute_group` type do not describe semantic convention and
are used for auxiliary purposes.

All semantic convention groups have the following common properties:

- identity - TODO - identifies span type, metric instrument name, or event name
among other spans, instruments, or events.
All telemetry items of this type and with this name are expected to follow this
semantic convention.
- `brief` and `note` describe the convention
- `stability` describes the maturity level of the convention
- `deprecated` property marks convention as deprecated and provides information about
replacement or other details.
- `attributes` lists references to applicable attributes in the [registry](../attributes-registry/README.md)

In addition to common properties, semantic convention groups have type-specific properties, see
[Schema documentation](https://github.com/open-telemetry/weaver/blob/main/schemas/semconv-syntax.md)
for the details.

## Group Stability

<!-- TODO: this section will need to change when https://github.com/open-telemetry/semantic-conventions/issues/1096 is implemented -->

Semantic Convention groups can be `stable` (corresponds to
[Stable maturity level][MaturityLevel]) or `experimental` (corresponds to [Development maturity level][MaturityLevel])
if stability level is not specified, it's assumed to be `experimental`.

Group stability MUST NOT change from `stable` to `experimental`.

Identifiable (TODO) semantic convention group of any stability level MUST NOT be removed
to preserve code generation and documentation for legacy instrumentations.

When group is renamed or no longer recommended, it SHOULD be deprecated.

See [Versioning and Stability][Stability] for the details on stability guarantees
provided for semantic convention groups of different types.

### Groups with mixed stability

Stability guarantees on a group apply to the group properties (such as type, identity and
signal-specific properties) as well as stable attribute properties referenced by this group.

Stability guarantees on a group level **do not** apply to experimental attribute references.

**Experimental groups:**

- MAY add or remove references to stable or experimental attributes
- MAY change requirement level and other properties of attribute references
Copy link
Contributor

Choose a reason for hiding this comment

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

Subject to more specific rules, e.g. metric groups where you CANNOT change requirement_level without it being a breaking change.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this is allow-list for experimental groups - breaking, but allowed

Copy link
Contributor Author

@lmolkova lmolkova Oct 14, 2024

Choose a reason for hiding this comment

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

I initially called it out in the stable group list below, but then decided that stable groups + stable attributes guarantees would belong in the https://github.com/open-telemetry/opentelemetry-specification/blob/0a78571045ca1dca48621c9648ec3c832c3c541c/specification/versioning-and-stability.md?plain=1#L217. WDYT?


**Stable groups:**

- MAY add or remove references to stable or experimental attributes with `opt_in`
Copy link
Contributor Author

Choose a reason for hiding this comment

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

removing stable opt-in is breaking

requirement level regardless of attribute stability.
- MUST NOT have references to experimental attributes with requirement level
Copy link
Contributor Author

Choose a reason for hiding this comment

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

we need to make it some exceptions for service and telemetry.sdk and maybe some other since they are populated by default

other than `opt_in`. The requirement level of an experimental attribute reference
MAY be changed when this attribute becomes stable in the cases allowed by the
[Versioning and Stability][Stability].

Stable instrumentations MUST NOT report telemetry following the experimental part
of semantic conventions by default. They MAY support experimental part and allow
users to opt into it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

future: publish two schemas - stable and stable+experimental (e.g. 1.28.0 and 1.28.0-dev)

[Stability]: https://opentelemetry.io/docs/specs/otel/versioning-and-stability/#semantic-conventions-stability
[MaturityLevel]: https://github.com/open-telemetry/oteps/blob/main/text/0232-maturity-of-otel.md
[DocumentStatus]: https://opentelemetry.io/docs/specs/otel/document-status
Loading