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.

What is the OpenTelemetry Semantic Conventions?

Searchable OpenTelemetry semantic convention attribute reference with namespace, type and stability status. Look up the canonical OTel attribute key for traces, metrics and logs. It runs free in your browser on Gera Tools, with nothing uploaded.

OpenTelemetry Semantic Conventions

Name: OpenTelemetry Semantic Conventions
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

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.

Key attribute namespaces at a glance

HTTP attributes (stable)

Attribute	Type	Example value
`http.request.method`	string	`"GET"`, `"POST"` (uppercase)
`http.response.status_code`	int	`200`, `404`
`url.full`	string	`"https://api.example.com/v1/orders"`
`url.path`	string	`"/v1/orders"`
`url.scheme`	string	`"https"`
`server.address`	string	`"api.example.com"`
`server.port`	int	`443`
`network.protocol.version`	string	`"1.1"`, `"2"`

Database attributes

Attribute	Type	Example value
`db.system`	string	`"postgresql"`, `"mysql"`, `"redis"`
`db.name`	string	`"orders_db"`
`db.operation`	string	`"SELECT"`, `"INSERT"`
`db.statement`	string	`"SELECT * FROM orders WHERE id = ?"`
`db.user`	string	`"app_user"`
`server.address`	string	Database host
`server.port`	int	`5432` (PostgreSQL default)

RPC attributes

Attribute	Type	Example value
`rpc.system`	string	`"grpc"`, `"jsonrpc"`, `"dotnet_wcf"`
`rpc.service`	string	`"OrderService"`
`rpc.method`	string	`"GetOrder"`
`rpc.grpc.status_code`	int	`0` (OK), `14` (UNAVAILABLE)

Exception event attributes

event name: "exception"
exception.type       = "java.lang.NullPointerException"
exception.message    = "Cannot invoke method getId() on null"
exception.stacktrace = "<full stack trace string>"

Migration: old vs new HTTP keys

Many codebases still use the pre-stable HTTP convention names. These are now deprecated:

Deprecated	Current stable equivalent
`http.method`	`http.request.method`
`http.status_code`	`http.response.status_code`
`http.url`	`url.full`
`http.host`	`server.address`
`http.flavor`	`network.protocol.version`

During migration, emit both old and new keys for one release cycle so existing dashboards and alerts keep working while you update queries.

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"

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. Always set service.name as a resource attribute so every signal from your service is correctly identified in your observability backend.