otel-semantic-conventions
OpenTelemetry Semantic Conventions expert. Use when selecting, applying, or reviewing telemetry attributes. Triggers on tasks involving attribute selection, semantic convention compliance, attribute migration, or custom attribute decisions. Covers the attribute registry, naming patterns, attribute p
By dash0hq · 595 installs
npx skills add dash0hq/agent-skills --skill otel-semantic-conventions
Source repository · Upstream listing
OpenTelemetry Semantic Conventions
This skill governs correct selection, placement, and validation of telemetry attributes and metric instruments according to the OpenTelemetry Semantic Conventions specification.
For span naming, span kinds, and span status codes, see the [otel instrumentation](../otel instrumentation/) skill.
The [Attribute Registry](https://opentelemetry.io/docs/specs/semconv/registry/attributes/) is the single source of truth for all defined attributes.
Rules
Rule Description Use Case
[attributes](./rules/attributes.md) Attribute registry, selection, placement, common attributes by domain Choosing or reviewing attributes; HTTP/DB/messaging/RPC attributes; attribute placement (resource vs span)
[versioning](./rules/versioning.md) Semconv versioning, stability, migration Semconv version migration
[dash0](./rules/dash0.md) Dash0 derived attributes and feature dependencies Dash0 derived attributes
Official documentation
[Attribute Registry](https://opentelemetry.io/docs/specs/semconv/registry/attributes/)
[Semantic Conventions Specification](https://opentelemetry.io/docs/specs/semconv/)
[Semantic Conventions Repository](https://github.com/open telemetry/semantic conventions)
[Dash0 Semantic Conventions](https://www.dash0.com/documentation/dash0/semantic conventions)
[Dash0 Semantic Conventions Explainer](https://www.dash0.com/knowledge/otel semantic conventions explainer)
How to select the right attribute
1. Search the registry first — Look up the concept in the [Attribute Registry](https://opentelemetry.io/docs/specs/semconv/registry/attributes/). Use the standard name if it exists (e.g., prefer http.request.method over a custom custom.http.verb ). Custom names fragment querying and break tooling — only create a custom attribute when no registry entry covers the concept.
2. Check stability — Prefer stable attributes; note any experimental attributes that may change. See [versioning](./rules/versioning.md).
3. Place at the correct level — Resource attributes describe the entity producing telemetry; span/log attributes describe the individual operation. Do not duplicate across levels. Once an attribute is at a given level, keep it there consistently across all services.
4. Verify cardinality — Metric attribute values must be low cardinality (bounded set). Variable data (user IDs, request paths with parameters) belongs in span attributes, not metric attributes.
5. Custom attribute as last resort — Only create a custom attribute if no registry entry covers the concept. Document the decision and follow the org.namespace.attribute name naming pattern.
Example: correct vs incorrect attribute selection
<! eval:skip
Example: resource vs span attribute placement
<! eval:skip
Example: cardinality violation in metric attributes
<! eval:skip