Difference between metrics and logs

WHAT THIS TESTS This checks foundational observability knowledge: that metrics and logs answer different questions and are used together, metrics for detection and trends, logs for detailed diagnosis.

A GOOD ANSWER COVERS Metrics are numeric measurements sampled and aggregated over time into time series, for example request latency percentiles, requests per second, error rate, CPU, and memory. They are compact, cheap to retain long-term, and excellent for dashboards, trend analysis, and threshold alerting; they tell you what is happening and when. Logs are discrete, timestamped records of individual events, often with rich context like request IDs, stack traces, and messages. They are bulkier but tell you why something happened, supporting detailed root-cause investigation. The two are complementary: metrics surface and quantify a problem, logs explain it. A senior answer may also mention traces as the third pillar linking a request across services.

COMMON WRONG ANSWERS Treating metrics and logs as the same thing. Claiming metrics alone reveal root cause. Saying logs are good for alerting on aggregate trends, which is expensive and awkward. Forgetting that logs carry context metrics lack.

LIKELY FOLLOW-UPS Where do traces fit? How do you control log volume and cost? Why are high-cardinality labels a problem for metrics? How do request IDs tie logs to a trace?

ONE CONCRETE EXAMPLE A user reports the app is slow. You open the metrics dashboard and see p99 latency for the checkout service jumped at 2 pm while throughput was normal, scoping the problem to one service and time. You then query that service's logs around 2 pm and find repeated database timeout errors with a specific query, revealing a slow query as the root cause, which the metrics alone could only hint at.