What are OpenTelemetry semantic conventions?

They are a standardized set of attribute names and values for telemetry data so that traces, metrics and logs from different systems are consistent and queryable. For example, every HTTP server span uses http.request.method rather than a custom per-vendor key.

Why did http.method change to http.request.method?

The HTTP conventions were stabilized in a way that namespaced request and response attributes. Older instrumentation used http.method and http.status_code; the stable versions are http.request.method and http.response.status_code. Bridge both during migration.

What does the stability column mean?

Attributes are marked Stable, Experimental or Deprecated. Stable attributes will not change name or meaning. Experimental ones may still change, and deprecated ones are superseded by a newer key and should not be used in new code.

How do I record an exception on a span?

Add an event named exception with the attributes exception.type, exception.message and exception.stacktrace. Most SDKs provide a recordException helper that populates these keys automatically from a caught error object.

Are these conventions the same for traces and metrics?

Many attribute keys are shared across signals so you can correlate them, but some conventions are signal-specific. The general resource and span attributes apply broadly, while metric names follow their own naming guidelines layered on the same namespaces.

OpenTelemetry Semantic Conventions

OpenTelemetry semantic conventions reference

OpenTelemetry semantic conventions define the canonical names and value formats for attributes attached to spans, metrics, and logs. Using them means a query like db.system = postgresql works the same whether the data came from a Java, Go, or Python service. This reference lists common attribute keys, the namespace they belong to, their value type, and stability status.

Filter by key or namespace below to find the right attribute name for your instrumentation.

How it works

Attributes are namespaced dotted keys (http., db., rpc., messaging., network., server.). The OpenTelemetry specification fixes both the name and the expected value — for instance http.request.method must be an uppercase token like GET, and db.system uses a known identifier like postgresql or mysql. Each attribute carries a stability marker: Stable keys are frozen, Experimental keys may still change, and Deprecated keys point to a replacement.

Exceptions are modeled as a span event named exception carrying exception.type, exception.message, and exception.stacktrace. Resource attributes (service.name, service.version, telemetry.sdk.name) describe the producing entity and apply to every signal it emits. Following the conventions is what makes vendor-neutral dashboards and alerting possible.

Tips and examples

A typical HTTP server span carries:

http.request.method = "GET"
url.path = "/api/orders"
http.response.status_code = 200
server.address = "api.example.com"
network.protocol.version = "1.1"

When migrating older code, emit both the deprecated and stable keys for a release so existing dashboards keep working. Prefer the SDK’s helper methods (setAttribute, recordException) over hand-writing keys to avoid typos. Stick to Stable attributes for production alerting; treat Experimental ones as best-effort.

OpenTelemetry Semantic Conventions

Email me this result

OpenTelemetry semantic conventions reference

How it works

Tips and examples