Monitoring vs logging vs tracing: what is the difference?

In this article

1. Before you start
2. Why interviewers ask this
3. What each one is
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This page is one step of the site reliability engineer interview questions learning path. Browse the whole learn library for neighbouring topics, and look up unfamiliar terms in the glossary.

Why interviewers ask this

A wrong answer here costs the whole debugging conversation. A candidate who calls the three "competing tools" signals that they have not run a production service. Candidates report this question in site reliability engineering (SRE) interviews and in the observability part of system design rounds.

The question separates people who can name tools from people who can debug. A weak answer lists products. A strong answer says what question each signal answers, in what order you use them during an incident, and what each one costs. A Staff-level answer adds the failure modes: averages that hide a slow tail, logs that cannot be searched by request, and traces that are sampled so the one you need may not exist. The incident response scenario answer shows where this order of work appears in a live round.

What each one is

Monitoring

Monitoring is a practice that collects, aggregates and displays numeric measurements of a running system over time, and alerts a person when those numbers cross a threshold or show a symptom, so it answers whether something is broken and how badly, and points toward why, usually with help from logs and traces.

Logging

Logging is a practice in which a program writes a timestamped record of each notable event, such as an error with its message or a completed payment, to a file or a stream, so engineers can read exactly what happened in one place at one time, long after the event.

Tracing

Tracing is a practice that records the path of one request as it passes through many services, as a tree of timed steps called spans that share one trace id, so engineers can see which service or call took the time or failed.

To be precise, the three signals are metrics, logs and traces, often called the three pillars of observability. Monitoring is the practice of alerting on them, mostly on metrics.

Monitoring in plain words

Think of the dashboard of a car: gauges for speed and temperature, and a warning light. It tells you something is wrong right now. The analogy breaks in one place: a dashboard shows a few fixed gauges, while a monitoring system lets you add a gauge for anything you can count.

Google's SRE book defines it as "collecting, processing, aggregating, and displaying real-time quantitative data about a system". It also says a monitoring system should address two questions: what is broken, and why. A metric, in the words of the OpenTelemetry metrics page, is "a measurement of a service captured at runtime". Monitoring answers whether something is broken.

Why an average is not enough

An average can look healthy while a slice of users suffers. The SRE book gives the example of a web service with an average latency of 100 milliseconds at 1,000 requests per second, where 1% of requests might easily take 5 seconds. That is 10 slow requests every second, and if they are the slow 1%, the other requests average only about 50.5 milliseconds.¹

A percentile is the value that a given share of measurements stay below. The book notes that the 99th percentile over a small window, such as one minute, can give a very early signal of saturation. So a good monitor alerts on a percentile, not on the mean, and the four golden signals it recommends for a user-facing system are latency, traffic, errors and saturation. Averages tell you the system is fine; percentiles tell you who is not.

Logging in plain words

Think of a ship's logbook: every notable event written down with the time. When something goes wrong, you read the entries around that time. The analogy breaks where a ship writes a few lines a day and a busy service writes millions, so you need search, not reading.

The OpenTelemetry logs page describes a log as "a timestamped text record, either structured (recommended) or unstructured, with optional metadata". Logging records what happened in one event. Its strength is detail: the exact error message, the input that caused it, the user and the code path. Its weakness is that a log line says nothing about the other services in the same request unless you add an identifier, which is why logs are most useful when they carry a trace id.

Tracing in plain words

Think of a parcel tracking page: each stop the parcel makes, with the time it spent there. A trace does the same for one request. The analogy breaks because a parcel moves in a line, while a request often fans out to several services at the same time.

The OpenTelemetry traces page says traces are essential to understanding the full "path" a request takes in your application. Each step of that path is a span, and every span records its parent, so the spans form a tree under one trace id. Tracing shows where time went in one request. Google built its tracing system, Dapper, because requests in large distributed systems span many services and machines, and one server's view cannot explain end-to-end behaviour.

How the three differ side by side

The diagram sets the three against each other. Monitoring answers whether something is broken. Logging records what happened in one event. Tracing shows where time went in one request. Each has a different data shape and a different weak spot.

Text description of the diagram

• Monitoring answers whether something is broken.
• Logging records what happened in one event.
• Tracing shows where time went in one request.

They overlap in practice. The SRE book counts logs inside white-box monitoring, which it defines as monitoring based on metrics exposed by the internals of the system, and Dapper "began as a self-contained tracing tool but evolved into a monitoring platform", per its authors. The OpenTelemetry primer names traces, metrics and logs together as the signals the application code must emit.

Worked example

This is an illustrative scenario, not a real incident. A checkout request passes through four services: gateway, cart, payment and inventory. Customers complain that checkout is slow. The figure shows the order of work; the steps below follow it. The numbers come from the SRE book example above plus values we made up and label as illustrative.¹

1 · Metric alert2 · Trace3 · Log4 · FixReplay

Step-by-step description

1. The metric alert says checkout is slow.
2. The trace shows which service is slow.
3. The log shows the error message.
4. The metric confirms the fix worked.

• The metric alert says that checkout is slow.
• The trace shows which service is slow.
• The log for that trace id shows the error message.

Step 1: The metric pages you

An alert on 99th percentile checkout latency fires. The metric alert says that checkout is slow. It does not say which service is at fault, and it does not need to: its job is to wake a person for a symptom users feel. The SRE book advises alerts with good signal and very low noise, because paging a human is expensive. Input: a stream of latency measurements. Output: one page about the slow tail.

Step 2: The trace shows which service is slow

You open one slow request from the tail. The trace shows which service is slow. In this illustrative case the gateway receives the request, so its span is the root span and lasts 4,910 milliseconds. That root span contains 15 milliseconds of the gateway's own work and three child spans called one after another: cart 30, payment 4,820 and inventory 45. The payment span is 4,820 of the root span's 4,910 milliseconds (98.2%).¹ Input: one trace id. Output: a single service to look at. The metric could never tell you this, because it has no notion of one request.

Step 3: The log shows the error

Now you read the logs of the payment service for that same trace id. The log for that trace id shows the error message. A hypothetical line looks like this:

level=error service=payment trace_id=a1b2c3 msg="card processor call timed out"

The trace said where; the log says what. Input: the trace id. Output: the exact error, which points to a slow outside dependency.

Step 4: Fix, then confirm with the metric

After you raise a timeout or fail over, the same metric tells you the fix worked: the tail falls and the alert clears. Monitoring closes the loop it opened. A last cost check: at an illustrative 1% sampling rate and 1,000 requests per second, about 10 traces per second are stored, and of the 10 slow requests per second, 0.1 per second is captured, which is 8,640 slow traces a day.¹ The 1% rate is our illustration, not Dapper's number; the paper credits sampling and instrumenting only a small number of common libraries for its low overhead.

Trade-offs and edge cases

The three signals trade detail against cost, and the textbook order (metric, then trace, then log) fails when one signal is missing. The cases below are where interview answers usually get specific.

Do the three signals overlap?

Yes, and that is a feature. Logs can be turned into metrics by counting error lines, and trace spans carry durations that become latency metrics. The OpenTelemetry primer describes observability as the ability to understand a system from the outside by asking questions without knowing its inner workings, and it says that helps with novel problems, the "unknown unknowns". Monitoring covers the questions you thought of in advance; the richer signals cover the ones you did not.

What does each one cost?

Costs grow differently. Monitoring cost grows with how many separate series you track, which is the metric's cardinality (the number of distinct label combinations); the OpenTelemetry metrics page covers it. Log cost grows with traffic, because every event is a line. Trace cost is controlled by sampling: Dapper limits overhead by sampling, and many systems also keep every slow or failed trace through tail sampling, which decides after the request finishes. A sampled trace may not exist for the request you need, so keep both a sampling policy and a trace id in every log line.

Should they live in one tool?

Not necessarily. The SRE book recommends keeping the metrics, alerting and dashboards system simple and loosely coupled to log analysis and other debugging tools, because blending too much makes systems fragile. That is Google's own experience, not a universal rule. OpenTelemetry, which generates and exports telemetry but is not itself a backend, lets you change the storage tool without re-instrumenting the code. For the wider picture of operating services, see the DevOps and cloud learning path.

How to answer it in an interview

The spoken structure: say they are complementary, give each one's question, walk the order of use, then name the cost trade-off.

Common mistakes

• "They are three competing tools; pick one." (wrong) Google's book counts logs inside white-box monitoring, and OpenTelemetry treats metrics, logs and traces as signals. (right) "They are complementary: metrics, logs and traces are the signals, and monitoring is the practice of alerting on them."
• "Average latency tells me the service is healthy." (wrong) The mean hides the tail. (right) "I alert on a high percentile and use the mean only as context."
• "I alert on every cause I can think of." (wrong) Alerts that page for causes create noise. (right) "I page on user-visible symptoms and keep alert rules simple."
• "Tracing is too expensive for production." (wrong) Dapper ran at low overhead through sampling. (right) "I sample, keep slow and failed traces, and put the trace id in the logs."

Follow-up questions

What is the difference between monitoring and observability?

Observability is the ability to understand a system from the outside by asking new questions, without knowing its inner workings, as the OpenTelemetry primer puts it. Monitoring is the practice of watching known measurements and alerting on them; it answers the questions you planned for.

Do you need all three signals?

For a small service, metrics and logs are often enough. Once a request crosses several services, a metric cannot say which one is slow and a log cannot show the whole request, so tracing earns its cost.

Which signal do you check first when an alert fires?

Start from the alert's metric to confirm the symptom, then open a trace of an affected request to find the service, then read that service's logs for the error. The SRE learning path covers the incident side of this order.

Is tracing too expensive to run in production?

Not when it is sampled. Dapper was deployed across virtually all of Google's systems with low overhead, crediting sampling and a small number of instrumented common libraries.

Where does OpenTelemetry fit in?

OpenTelemetry is an open-source, vendor-neutral framework for generating, collecting and exporting traces, metrics and logs. It is not an observability backend, so you still choose where the data is stored and viewed.

What are the three pillars of observability?

Metrics, logs and traces: the three signals that, per the OpenTelemetry primer, application code must emit for a system to be observable. They complement each other rather than rank, and a shared trace id ties them together.

Sources

1. Chapter 6: Monitoring Distributed Systems (Site Reliability Engineering) — Google (Ewaschuk, SRE book), 1 Jan 2016
2. Observability primer — OpenTelemetry, 23 Apr 2026
3. Logs (OpenTelemetry signals) — OpenTelemetry, 7 Aug 2026
4. Traces (OpenTelemetry signals) — OpenTelemetry, 14 Jan 2026
5. Metrics (OpenTelemetry signals) — OpenTelemetry, 2 Jul 2026
6. What is OpenTelemetry? — OpenTelemetry, 26 Oct 2026
7. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure — Google Research (Sigelman et al.), 1 Apr 2010