dcd39bf86e
## Changes
This PR marks the set of resource semantic conventions, which a relied
upon in stable API / SDK specification, as stable themselves.
- Add a caveat that changing `service.*` and `telemetry.*` names need
MORE than just schema file changes.
- Mark core Resource attribute semconv document as MIXED stability
- Update key sections for Resource attribute semconv as stable
- Mark `telemetry.sdk` and `service` attribute groups as stable.
- Move `telemetry.auto` and `service.*` "contentious" attributes into
`{section}_experimental.yaml` file. This retains the reserved name, but
does not mark the convention as stable, allowing us to ensure stable
portions of our specification refer to stable semconv.
- Update examples for `service.instance.id` to include an example of the
preferred style instance id before the fallback.
Related issues #3177
## Usage in the Specification
One reason we should mark these attributes as stable is because they are
referenced from numerous stable portions of our specification, and they
are also leveraged from newly stabilizing portions of our specification.
- [Resource
SDK](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/sdk.md#sdk-provided-resource-attributes)
- stable
- [Environment
Variables](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-environment-variables.md#general-sdk-configuration)
- stable
- [Jaeger
Exporter](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk_exporters/jaeger.md#resource)
- stable
- [Zipkin
Exporter](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk_exporters/zipkin.md#service-name)
- Stable
- [Log
DataModel](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#rfc5424-syslog)
- Stable
- [Prometheus
compatibility](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/prometheus_and_openmetrics.md#resource-attributes)
- still experimental
- [Performance Benchmark
Guidelines](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/performance-benchmark.md)
## A note on ECS compatibility
Here's [ECS service
definition](https://www.elastic.co/guide/en/ecs/current/ecs-service.html).
They include more attributes than we do. The only possible conflict
between us is `service.instance.id` vs. `service.node.name`. In this
case, our `service.instance.id` has a fallback of generating UUID which
is inconsistent w/ `service.node.name` which requires a user-generated
name if another name cannot be provided.
There's an opportunity for us to unify here. However, I don't think
there's appetite in OTEL to require user-specified names in lieu of some
algorithm or generative specification.
|
||
|---|---|---|
| .. | ||
| logs | ||
| metrics | ||
| resource | ||
| scope/exporter | ||
| trace | ||
| README.md | ||
| exception.yaml | ||
| http-common.yaml | ||
| user-agent.yaml | ||
| version.properties | ||
README.md
YAML Model for Semantic Conventions
The YAML descriptions of semantic convention contained in this directory are intended to be used by the various OpenTelemetry language implementations to aid in automatic generation of semantics-related code.
⚠ If you want to read the semantic conventions and not edit them, please see
the generated markdown output under /specification/*/semantic_conventions/,
i.e.:
Writing semantic conventions
Semantic conventions for the spec MUST adhere to the attribute naming, attribute requirement level, and metric requirement level conventions.
Refer to the syntax for how to write the YAML files for semantic conventions and what the YAML properties mean.
A schema file for VS code is configured in the /.vscode/settings.json of this
repository, enabling auto-completion and additional checks. Refer to
the generator README for what extension you need.
Generating markdown
These YAML files are used by the make target table-generation to generate consistently
formatted Markdown tables for all semantic conventions in the specification. Run it from the root of this repository using the command
make table-generation
For more information, see the semantic convention generator in the OpenTelemetry build tools repository. Using this build tool, it is also possible to generate code for use in OpenTelemetry language projects.
See also: