Three Pillars of Observability: Metrics, Logs, and Traces
Fast recall
Quick revision
Core answer
Whether the candidate understands observability as a discipline, not just individual tools.
Conflating monitoring with observability, or treating logs as the only signal.
Explain the cost and aggregation trade-offs of each pillar and how they complement each other in an incident workflow.
Interview-ready guide
Interview answer
Metrics, logs, and traces are called the three pillars of observability because each one answers a different kind of question about a running system — and you need all three to diagnose production problems effectively.
Metrics — how much, how often
- Metrics are numeric measurements sampled over time: request count, error rate, CPU usage, JVM heap percentage — which means you can set thresholds and alert before users notice a problem
- Micrometer collects metrics from Spring Boot automatically (HTTP latency, JVM, HikariCP) and pushes them to backends like Prometheus, CloudWatch, or Stackdriver; dashboards visualize trends over hours and days
Logs — what happened
- Logs capture discrete events with context — "user 123 placed order 456", "payment service returned 500" — which means they're the right tool for debugging exactly what happened in a specific request
- Structured JSON logs are queryable in Elasticsearch or CloudWatch Logs Insights; plain-text logs are grep-able but lose the ability to filter by field values across thousands of log lines
Traces — where time was spent
- A distributed trace assigns a unique trace ID to an incoming request and propagates it through every downstream service call — which means you can see the full journey of one request: 200ms in service A, 450ms in service B waiting for database, 10ms in service C
- Spring Cloud Sleuth (or Micrometer Tracing in Spring Boot 3) auto-instruments HTTP, messaging, and database calls; Jaeger or Zipkin collects and visualizes the trace spans
Using all three together
- A typical incident flow: an alert fires on a metrics spike (error rate > 1%) → search logs for ERROR entries in that time window → find the trace ID in the logs → open the trace in Jaeger to see which downstream call is failing or slow
- This flow requires correlation IDs (trace ID, request ID) to be present in both logs and traces so you can jump between tools
Three Pillars of Observability: Metrics, Logs, and Traces
Direct Answer
Metrics answer 'how much/how often', logs answer 'what happened', and traces answer 'where did the time go'. Together they let you understand, diagnose, and alert on any system behaviour from the outside.
Common Mistakes & Pitfalls
Conflating monitoring with observability, or treating logs as the only signal.
Check your understanding
Answer these without looking back at the article.
- How do you correlate a log entry with the trace that produced it?
- What is the difference between observability and monitoring?
- When would you choose tracing over logging for a latency investigation?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.