Observability Beyond the Three Pillars: Logs, Metrics, Traces, and Events

Why the three pillars are not enough

Logs, metrics, and traces are useful telemetry types. They are not a complete model of observability. The three pillars model implies that if you collect all three, you are observable — which is empirically false. Most outages we have investigated had complete telemetry and an opaque root cause.

Observability is a property of a system: the ability to ask new questions about the system without changing the code that produced the telemetry. That requires high-cardinality, structured event data, not just three separate data shapes.

Structured events as the unit of observability

A structured event is a wide row of context — request ID, user ID, route, latency, status, feature flag values, downstream calls, error class — emitted once per logical operation. From a stream of events you can derive metrics, traces, and logs as views.

This is the model OpenTelemetry traces converge toward when used properly: a span is a structured event with parent-child relationships. The pillars are slices of the same underlying data.

OpenTelemetry is the standard

In 2026 there is no good reason to start a new project with a vendor-specific instrumentation SDK. OpenTelemetry is the standard for traces and metrics, increasingly for logs, and is supported by every credible backend. Lock-in moves from the SDK to the backend — a much smaller, more revisitable decision.

The OTLP protocol means you can route the same telemetry to multiple backends during a migration. Use that. Run new and old in parallel for a month before cutting over.

Sampling without lying

Full trace retention is expensive. Head sampling — keeping one in N traces — discards exactly the traces you need (errors and tail-latency requests are rare by definition). Tail sampling, where the decision happens after the trace is complete and informed by the trace's properties, is the right pattern.

OpenTelemetry Collector implements tail sampling natively. Configure it to keep 100 percent of errors, 100 percent of slow requests, and a small uniform sample of healthy traffic.

SLOs as the language of reliability

Telemetry without SLOs is noise. An SLO is a contract — 99.9 percent of requests succeed in under 200ms over a 28-day window — that gives you a budget for failure and a forcing function for prioritization. Without SLOs, on-call rotates between alerts that may or may not matter.

Define SLOs per user journey, not per service. Users do not care that a service had 99.99 percent uptime; they care that they could check out.

Cost as a real constraint

Observability cost scales with traffic and cardinality. A team that adds user_id as a label to every metric will see their bill ten times over within a quarter. Reserve high-cardinality fields for traces and events; keep metrics low-cardinality.

Most modern observability backends offer indexed-on-read for events, which is much cheaper than indexed-on-write for high-cardinality dimensions. Use it.