OTel signals, Semantic Conventions, and the OTLP wire format

Your metrics backend runs on vendor-A. Your logs go to vendor-B. Your traces go to vendor-C. A request fails — and no two backends agree on the field name for the service. Cross-signal correlation is a spreadsheet exercise. OTel Semantic Conventions are the fix.

Three signals, one data model

OTel covers three signal types in stable form. Each has its own API surface, SDK pipeline, and OTLP message shape, but they share two concepts: Resource (per-emitter attributes — service.name, host.name, cloud.region, set once at service start) and Trace Context (trace_id, span_id) that lets you jump from a log line to the corresponding trace.

Traces — GA since 2021. The workhorse. Every backend speaks it. A trace is a tree of spans, each with a start time, duration, status, and attributes. The join key across services is the trace_id propagated via the W3C traceparent header.

Metrics — GA since 2023. The API supports counter, gauge, histogram, and exponential histogram (the new default for high-resolution latency, replacing fixed buckets). Metrics aggregate inside the SDK before export; the wire format carries resource-metrics batches.

Logs — API stable late 2023, SDKs stable late 2024. Bridge libraries (the “OTel log bridge” for slf4j, structlog, pino) let existing code emit OTel logs without rewrites. The wire format carries resource-logs batches with the same trace_id/span_id fields as traces.

Profiles — experimental in late 2024/2025, GA expected in 2026 as a fourth signal.

Semantic Conventions: the shared vocabulary

Independent of the four-piece architecture, OTel publishes Semantic Conventions — a normative set of attribute names for common operations.

• Resource: service.name, service.version, deployment.environment, host.name, cloud.region
• HTTP: http.request.method, http.route, http.response.status_code, url.full
• Database: db.system, db.operation, db.namespace
• Messaging: messaging.system, messaging.destination.name, messaging.operation

These are the join keys that make metrics, logs, and traces compose. Adopting Semantic Conventions is the highest-leverage discipline in OTel — every backend’s auto-derived dashboards and every cross-team query depends on consistent population. Mature platform teams ship a per-language wrapper around the OTel SDK that pre-configures attribute extraction so it cannot be forgotten.

OTLP: the wire format that ties everything

OTLP is a protobuf-defined wire protocol with two transports:

• OTLP/gRPC — binary protobuf over HTTP/2. Preferred. ~50-70% smaller payload than JSON, ~2-5× faster to encode. Supports streaming.
• OTLP/HTTP — protobuf or JSON over HTTP/1.1. Exists for environments that block gRPC (some firewalls) or for browser-side telemetry.

The three OTLP service messages are ExportTraceServiceRequest, ExportMetricsServiceRequest, and ExportLogsServiceRequest. Every OTel-compatible backend exposes an OTLP endpoint. The wire format has been stable for years and evolves backward-compatibly.

The vendor-neutrality contract: if your edge (the application or its sidecar) emits OTLP, you are vendor-neutral. If your edge emits a proprietary format, you are not — even if a gateway later converts.