Explain the three pillars of observability

WHAT THIS TESTS This checks whether you understand that metrics, logs, and traces serve distinct, complementary purposes, and whether you can describe a realistic workflow that uses each at the right stage of debugging.

A GOOD ANSWER COVERS Define each. Metrics are aggregated numeric measurements over time, like request rate, error rate, and latency percentiles; they are cheap, compact, and ideal for dashboards and alerting, answering is something wrong and how is the trend. Logs are discrete, timestamped event records with rich, often structured context; they answer what exactly happened in this case, including error messages and parameters. Traces follow a single request as it propagates across services and components, recording spans with timing, answering where in the distributed path did the time go or the failure occur. Stress complementarity: metrics tell you something is wrong, traces tell you where, logs tell you why. The classic flow is detect via metric alert, narrow with a trace, then read the relevant logs for root cause.

COMMON WRONG ANSWERS Treating the three as interchangeable. Saying metrics alone are enough, missing context. Confusing logs with traces. Logging everything verbosely at high cardinality, conflating logs with metrics. Ignoring that traces are essential specifically in distributed systems.

LIKELY FOLLOW-UPS How do you correlate the three, for example with a trace ID in logs? What are the cost tradeoffs? What is high cardinality and why does it strain metrics? Where do exemplars fit?

ONE CONCRETE EXAMPLE A latency dashboard, a metric, shows p99 spiking at 9 a.m. You pull a trace of a slow request and see ninety percent of the time spent in the recommendations service call. You then read that service's structured logs for those requests and find a database connection pool exhausted error. Metric found the symptom, trace localized it, logs revealed the cause, illustrating exactly why all three pillars matter together.