OTel Semantic Conventions: What to Use Where

OpenTelemetry has hundreds of semantic conventions. The ones that matter for SRE, with concrete examples.

HTTP attributes

OpenTelemetry semantic conventions are the standardized attribute names for common observability data. Following the conventions produces telemetry that works across vendors, tools, and analyses without translation. Ignoring them produces telemetry that requires per-tool mapping; the cost compounds across the team's lifetime.

What HTTP attributes the conventions specify:

• http.method.: The HTTP method (GET, POST, PUT, DELETE, etc.). The standard name is http.method; not method, http_method, requestMethod, or any other variation. The standard means tools recognize it without configuration.
• http.status_code.: The HTTP response status code. The standard name is http.status_code. Tools can filter, aggregate, and visualize by status code consistently.
• http.route.: The matched route pattern (e.g., /users/{id}, not /users/12345). The standard name is http.route; the value is the pattern with parameter placeholders, not the literal URL.
• Standard names mean cross-vendor and cross-tool compatibility.: Datadog dashboards, Honeycomb queries, Grafana panels all recognize the standard names. The team can switch tools without rewriting their queries; the data is portable.
• Avoid custom names that mean the same thing.: Custom names like httpMethod, statusCode, or routeTemplate produce telemetry that tools do not recognize automatically. The team's queries become tool-specific; portability is lost. Using the standard preserves portability.

HTTP attributes are the most-used set. Following the conventions here is the highest-leverage adoption.

RPC attributes

RPC attributes capture the same patterns for non-HTTP RPC systems (gRPC, Thrift, custom protocols). The conventions are similar in spirit to HTTP but adapted for RPC's specifics.

• rpc.system.: The RPC system in use (grpc, thrift, dubbo). The standard name is rpc.system; the value identifies the framework. Tools can apply RPC-specific analyses based on this value.
• rpc.service.: The service being called (e.g., UserService). The standard name is rpc.service. The service name supports per-service aggregation in tooling.
• rpc.method.: The method being called (e.g., GetUser). The standard name is rpc.method. The method name supports per-method analysis.
• Standard means traces work in any backend.: A trace produced with standard RPC attributes is queryable in Datadog, Honeycomb, Tempo, Jaeger. The compatibility is the value.
• Internal RPC layer should follow the standard.: Even if the team wraps RPC in custom abstractions (typical for internal RPC frameworks), the abstraction should emit the standard attributes. The instrumentation layer knows the standard names; the wrapping does not require renaming.

RPC attributes are essential for service-to-service tracing. The standard adoption pays off in tool compatibility.

Kubernetes attributes

Kubernetes attributes describe where the telemetry-emitting workload is running. The conventions support correlating telemetry with cluster resources.

• k8s.pod.name.: The pod name. Standard name is k8s.pod.name. Tools can correlate metrics, traces, and logs from the same pod.
• k8s.namespace.name.: The namespace. Standard name is k8s.namespace.name. Per-namespace queries work consistently across tools.
• k8s.container.name.: The container name within the pod. Standard name is k8s.container.name. Multi-container pods (sidecar patterns) can be analyzed at the container level.
• Standard means tools can correlate without custom config.: The team's tools can join telemetry data from different sources using the standard attributes. The correlation produces unified views without per-source configuration.
• Most OTel SDKs auto-populate these.: The SDKs detect Kubernetes context and auto-populate the standard attributes. The team's instrumentation does not need to specify them; they appear automatically.
• Verify; sometimes the auto-fills are off.: Auto-population works in most environments but can fail in unusual configurations. The team should verify the attributes are present in their telemetry; missing auto-fills are a configuration issue to fix.

OTel semantic conventions are one of those small disciplines that compound across the team's observability lifetime. Nova AI Ops integrates with telemetry produced under the standard conventions, surfaces convention violations, and produces the consistency that makes cross-tool observability work.