Logging & Observability interview question · Most asked

What are the three pillars of observability, and how do they differ?

Summary

Logs record discrete events with context, metrics are numeric time series aggregated over time, and traces follow a single request across services. Together they let you detect, diagnose and explain problems in production.

Longer Answer

Metrics (request rate, error rate, latency percentiles, CPU) are cheap to store and great for dashboards and alerts. They tell you that something is wrong. Traces show the path and timing of one request through services, databases and queues, so they tell you where. Logs carry rich detail about individual events (errors, decisions, inputs), so they tell you why.

Modern systems correlate the three with shared identifiers (trace ID in log lines, exemplars linking metrics to traces). Some teams add profiles (continuous profiling) and events as further signals. Observability is about being able to ask new questions of your system without shipping new code.

Key Points

  • Metrics: detect (cheap, aggregated)
  • Traces: locate (per-request path and timing)
  • Logs: explain (detailed events)
  • Correlate with trace IDs
  • Profiles are an emerging fourth signal

Comparison / Tradeoffs

Signal Answers Cost Typical tools
Metrics Is something wrong? Low Prometheus, CloudWatch
Traces Where is it slow/failing? Medium (sampled) OpenTelemetry, Jaeger, Tempo
Logs Why did it happen? High at volume ELK/OpenSearch, Loki

Explanation

What interviewers look for

Understanding of what each signal is good at and how they're connected in practice.

Common mistakes

  • Treating logging as observability
  • Logging everything at DEBUG in production instead of using metrics

Follow-up questions

  • How would you correlate a slow request in a dashboard to its logs?

More most-asked Logging & Observability questions

← All Logging & Observability questions