The three pillars of observability
Summary: observability rests on three complementary types of data. Metrics answer "is there a problem?". Logs answer "what exactly happened?". Traces answer "where, in my chain of services, is the problem located?". This lesson details each one, with its costs and pitfalls, then presents the emerging fourth pillar.
1. Overview of the three pillars
The most important point of this lesson: these three pillars are not competitors, they chain together in a diagnosis flow. A team that only had logs would spend its time looking for a needle in a haystack. A team that only had metrics would know a problem exists without ever being able to explain it.
2. Pillar 1 — Metrics
The four types of metrics
The most useful practical advice: for latency, always use a histogram, never a gauge of the average. The average is misleading — that is the subject of lesson 4.
3. Pillar 2 — Logs
Unstructured log versus structured log
Here is the concrete difference, which radically changes usability.
// Unstructured log: readable by a human, painful for a machine
"2026-08-06 14:32:11 ERROR Payment failure order 4471 amount 89.90 user 8823"
// Structured log: queryable like a database
{
"timestamp": "2026-08-06T14:32:11.482Z",
"level": "error",
"message": "Payment failed",
"service": "payment",
"version": "2.14.3",
"order_id": 4471,
"amount": 89.90,
"currency": "EUR",
"user_id": 8823,
"payment_provider": "stripe",
"error_code": "card_declined",
"duration_ms": 1842,
"trace_id": "4bf92f3577b34da6a3ce929d0e0e4736"
}
What the structured format allows and free text forbids: "show me all the payment failures of the last 24 hours, with the error code card_declined, for an amount above 50 euros, grouped by payment provider". This query is immediate on JSON, nearly impossible on free text.
The most important field in this example: trace_id. It is what links this log to the complete trace of the request, and therefore connects pillars 2 and 3.
Log levels and their proper use
| Level | When to use it | Should it alert? |
|---|---|---|
| ERROR | An operation failed and requires attention | Often yes |
| WARN | A handled anomaly, but abnormal (successful retry) | Watch the trend |
| INFO | A notable business event (order created, login) | No |
| DEBUG | Technical detail useful during investigation | No, disabled in production |
| TRACE | Very fine-grained detail, rarely enabled | No |
A very frequent mistake: leaving the DEBUG level enabled in production. The log volume explodes, the cost follows, and useful information becomes impossible to find in the noise.
4. Pillar 3 — Traces
What a trace looks like
This is exactly what no metric can tell you. A metric tells you "the latency of the orders service is 2.3 seconds". The trace shows you why: 45 successive calls instead of a single batched call. The diagnosis takes a few seconds instead of several hours.
The "N+1" problem illustrated here is extraordinarily frequent — it is probably the most common cause of slowness in applications, and distributed tracing makes it immediately visible.
Sampling
5. The emerging fourth pillar — continuous profiling
Why mention it in a discovery course: continuous profiling appears more and more in job postings and technical discussions. Knowing that it exists and what question it answers already sets you apart from the majority of candidates.
6. The pillar comparison table
| Criterion | Metrics | Logs | Traces | Profiles |
|---|---|---|---|---|
| Question | Is there a problem? | What happened? | Where in the chain? | Which line of code? |
| Nature | Aggregated numbers | Textual events | Request journey | CPU samples |
| Storage cost | Very low | High | Medium | Low to medium |
| High cardinality | No | Yes | Yes | Partially |
| Typical retention | Months to years | Days to weeks | Days | Days |
| Main use | Alerting | Diagnosing | Locating | Optimizing |
| Common tool | Prometheus | Loki, ELK | Jaeger, Tempo | Pyroscope |
What this table lets you decide: if your observability budget is constrained, the order of priority is clear. Metrics first (minimal cost, immediate value), structured logs next (with a short, deliberate retention), traces when you exceed three or four services.
7. How to connect them — correlation
This is what distinguishes a good setup from a mediocre one.
The practical difference is spectacular. Without correlation, an engineer opens three different interfaces and tries to match timestamps by hand. With correlation, they navigate in one click from the alert to the faulty line of code. It is often the difference between twenty minutes and two hours of diagnosis.
Remember in 30 seconds
- Metrics → "is there a problem?". Cheap, aggregated, the basis of alerts. Low cardinality only.
- Logs → "what exactly happened?". Maximum detail, high volume and cost. Always structured (JSON).
- Traces → "where in my chain of services?". Essential beyond three or four services.
- Profiles (emerging 4th pillar) → "which line of code?". Pyroscope, Parca.
- The pillars chain together: metric alerts → trace locates → logs detail.
- Four types of metrics: counter, gauge, histogram (the right choice for latency), summary.
- For traces, prefer tail-based sampling: keep 100% of errors and slow requests.
- Never leave the DEBUG level enabled in production — volume and cost explode.
- Correlation by trace identifier is what distinguishes a good setup. Standard: W3C Trace Context.
- Order of priority if budget is constrained: metrics → structured logs → traces.
Next: What exactly should you measure? The four golden signals →