agentleFS
dash0hqdash0hq/agent-skills/skills/otel-semantic-conventions/SKILL.md

otel-semantic-conventions

Skill99 starsChanged 13 days agoApache-2.0View on GitHub

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 placement, and versioning. For span names, span kinds, and span status codes, see the otel-instrumentation skill.

2 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 1

    1. osabiohq/osabio★ 1535% same

    Wrote their own version · 1

    1. ollygarden/opentelemetry-agent-skills★ 125same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository4 other files it gives its agents.

The file

Files
SKILL.md

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 skill.

The Attribute Registry is the single source of truth for all defined attributes.

Rules

RuleDescriptionUse Case
attributesAttribute registry, selection, placement, common attributes by domainChoosing or reviewing attributes; HTTP/DB/messaging/RPC attributes; attribute placement (resource vs span)
versioningSemconv versioning, stability, migrationSemconv version migration
dash0Dash0 derived attributes and feature dependenciesDash0 derived attributes

Official documentation

How to select the right attribute

  1. Search the registry first — Look up the concept in the Attribute Registry. 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.
  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 -->
# Correct — uses registry attribute for HTTP method
span.set_attribute("http.request.method", "GET")

# Incorrect — invents a custom attribute for a concept already in the registry
span.set_attribute("custom.http.verb", "GET")

Example: resource vs span attribute placement

<!-- eval:skip -->
# Correct — service identity is a resource attribute
resource = Resource({"service.name": "checkout-service", "service.version": "2.1.0"})

# Correct — operation-specific data is a span attribute
span.set_attribute("http.request.method", "POST")
span.set_attribute("http.response.status_code", 201)

# Incorrect — placing a resource-level attribute on every span
span.set_attribute("service.name", "checkout-service")  # belongs on the resource

Example: cardinality violation in metric attributes

<!-- eval:skip -->
# Correct — metric attribute uses a bounded, low-cardinality value
histogram.record(duration_ms, {"http.request.method": "GET", "http.response.status_code": 200})

# Incorrect — unbounded values as metric attributes explode storage and query cost
histogram.record(duration_ms, {"user.id": "u-839201", "url.path": "/orders/839201"})
# Fix: move high-cardinality values to span attributes instead
span.set_attribute("user.id", "u-839201")
span.set_attribute("url.path", "/orders/839201")

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.