Observability Fundamentals
Fast recall
Quick revision
Core answer
Whether you understand observability as the three pillars (logs, metrics, traces) and the principle of asking new questions without redeploying — not just 'we have logging'.
Equating observability with 'we have logs' — logs alone can't answer aggregate questions (error rate) or cross-service questions (where is the latency), which metrics and traces provide.
Name the three pillars (structured logs for events, metrics for aggregates, traces for request flow across services), distinguish each by what question it answers, and frame observability as asking new questions without redeploying.
Interview-ready guide
Interview answer
Observability is a system's ability to let you understand its internal state from its external outputs — telemetry — rather than by inspecting it directly.
It exists because modern distributed systems have too many moving parts to inspect directly, and the failure modes are emergent — a slow downstream, a retry storm, a partial outage — not a single crashed process. The three pillars are structured logs, which answer what happened; metrics, which answer how much or how many; and distributed traces, which answer where the time or error went.
The key that ties them together is a correlation or trace ID propagated across services, so a single slow trace can be matched to the logs and metrics for that exact request. The principle I stress is instrumentation over retro-fitting — emit telemetry in code with Micrometer or OpenTelemetry so you can ask new questions of a running system without redeploying to add a print statement.
And I'm honest that full telemetry is expensive, so we sample traces and prioritize structured logs for errors and metrics for SLOs; the four golden signals — latency, traffic, errors, saturation — are the service-health baseline.
Observability Fundamentals
Direct Answer
Observability is a property of a system: the ability to understand its internal state from its external outputs (telemetry) — logs, metrics, and traces. It exists because modern distributed systems (microservices, containers, cloud) have too many moving parts to inspect directly, and the failure modes are emergent (a slow downstream, a retry storm, a partial outage) rather than a single crashed process. You cannot debug what you cannot see, so observability builds the three telemetry pillars — logs, metrics, traces — and the instrumentation that lets you ask new questions of a running system without redeploying.
Common Mistakes & Pitfalls
Equating observability with 'we have logs' — logs alone can't answer aggregate questions (error rate) or cross-service questions (where is the latency), which metrics and traces provide.
Check your understanding
Answer these without looking back at the article.
- What are the three pillars of observability, and what question does each answer?
- Why is structured logging (JSON fields) better than free-text logging for observability?
- How does a trace ID correlate logs, metrics, and traces across services, and what breaks it?
- What are the four golden signals, and why are they the service-health baseline?
- Why must observability be instrumented in code rather than retro-fitted at the platform?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.