# What are the Three Pillars of Observability?

> The three pillars of observability are logs, metrics, and traces - the core telemetry signals used to understand, debug, and operate modern software systems.

Source: https://openobserve.ai/glossary/three-pillars-of-observability/
Published: 2026-07-08
Term: Three Pillars of Observability
Category: Observability Fundamentals
Related terms: what-is-observability, what-is-telemetry, what-is-distributed-tracing, what-is-log-management

---

The **three pillars of observability** are **logs**, **metrics**, and **traces** - the three complementary telemetry signals that together describe what a software system is doing. Each answers a different kind of question, and mature observability practices correlate all three.

## Logs: what happened

Logs are timestamped, often structured records of discrete events: an error was thrown, a request was served, a configuration changed. They carry the richest context of any signal - stack traces, user IDs, payload details - which makes them the signal of last resort when debugging. Their weakness is volume: verbose services can produce terabytes per day, which is why [log management](/glossary/what-is-log-management/) cost and retention strategy matter so much.

## Metrics: how much and how fast

Metrics are numeric measurements sampled over time: request rate, error rate, p99 latency, memory usage. They are cheap to store, fast to query, and ideal for dashboards, [SLOs](/glossary/slo-sla-sli/), and alerting. Frameworks like the [four golden signals](/glossary/four-golden-signals/) describe which metrics matter most. Their weakness is aggregation - a metric tells you *that* latency spiked, not *why*, and [high-cardinality](/glossary/what-is-high-cardinality/) labels can explode storage costs in some systems.

## Traces: where it happened

Traces follow a single request as it flows through a distributed system, recording a [span](/glossary/what-is-a-span/) for each operation along the way. They reveal which service, query, or downstream call was responsible for latency or errors - something neither logs nor metrics can show across service boundaries. See [distributed tracing](/glossary/what-is-distributed-tracing/) for how this works.

## The pillars work together

The real power is in correlation. A typical investigation moves across all three: an alert fires on a metric → you open the slow traces from that window → you pivot to the logs of the failing span. If your logs, metrics, and traces live in three disconnected tools, that workflow means copy-pasting timestamps between browser tabs.

## The three pillars in OpenObserve

OpenObserve stores [logs](/logs/), [metrics](/metrics/), and [traces](/traces/) in one platform with shared dashboards and cross-signal correlation, ingesting all three natively via OpenTelemetry - so the pivot from metric to trace to log happens in one place.