OTel signals, Semantic Conventions, and the OTLP wire format

Three signals, one data model

By the end of this lesson you will know why correlating a metrics alert to a failing trace is a one-click operation in OTel — and why it is a spreadsheet nightmare without Semantic Conventions.

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

Ask yourself: if every team in a 50-service fleet names the HTTP route attribute differently, how many cross-team queries will silently return zero results? That is the problem Semantic Conventions solve.

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.