What is the difference between monitoring and distributed tracing?

How to think about it

Monitoring answers whether a population of requests or hosts is healthy over time. Distributed tracing answers what happened to one request as it crossed services. Monitoring uses aggregated signals such as request rate, error rate, latency percentiles, and capacity; tracing links timed operations into a request’s journey. Monitoring detects the problem. Tracing helps explain it.

Why the distinction matters

Suppose a checkout API normally serves 1,000 requests per minute with a p95 latency of 480 milliseconds. The p95 is the latency at or below which 95 percent of requests finish. One afternoon, p95 rises to 2.4 seconds.

A monitoring dashboard can tell you several useful things quickly:

• The problem affects a significant slice of traffic, not just one unlucky customer.
• It began at 14:07.
• It affects the European region but not North America.
• The error rate is still low, so this is mainly a latency incident.
• The database connection pool is close to capacity.

That is excellent for detection and scope. But the dashboard usually cannot tell you whether the delay came from the checkout service, a payment provider, a database query, or time spent waiting in a queue.

A distributed trace preserves the identity of one request. It follows that request through the gateway, checkout service, pricing service, database, payment provider, and other dependencies. Each timed operation is called a span, and all the related spans share a trace ID, an identifier for the complete request journey. Parent and child relationships show which operation called which.

The difference is therefore not simply “metrics versus a fancier dashboard.” It is a difference in granularity:

Tool	Unit of observation	Main question
Monitoring	Many requests, hosts, or jobs over time	Is the system unhealthy, and how broadly?
Distributed tracing	One request or transaction	Where did this request wait, fail, or slow down?

Metrics deliberately throw away request identity so that they remain compact and fast to query. A metric might be grouped by route, region, status code, and service. It normally should not be grouped by user ID or request ID. Those labels create high cardinality, meaning a large number of distinct label combinations, which makes metric storage and queries expensive.

Tracing makes the opposite trade-off. It retains much more detail about individual requests, so it can answer questions that an aggregate cannot.

A concrete checkout example

The checkout dashboard shows this change:

Signal	Before 14:07	After 14:07
Request rate	1,000 per minute	1,020 per minute
Error rate	0.4 percent	0.6 percent
p95 latency	480 ms	2,400 ms
Database CPU	52 percent	58 percent
Queue age	1 second	2 seconds

The request rate and error rate look mostly normal. Latency is the clue. A monitoring alert might fire because the checkout SLO, or service-level objective, is being violated.

The engineer then opens a slow trace from the affected region:

Span	Duration	What it shows
API gateway	2,430 ms	Total request time at the edge
Checkout service	2,400 ms	Time inside the application
Pricing service	85 ms	Normal pricing lookup
Inventory service	1,950 ms	Main delay
PostgreSQL query	1,820 ms	Slow query nested inside inventory
Payment provider	300 ms	Expected external call

The trace localizes the issue to the inventory path and, more specifically, to a PostgreSQL query. The engineer can now inspect database logs, query plans, locks, or recent schema changes instead of paging every service owner in alphabetical order.

The durations are nested. You must not add the gateway, checkout, and child spans together, because parent spans include the work of their children. The PostgreSQL span is part of the inventory span, and the checkout span includes both. This is a common tracing mistake in interviews and in production dashboards.

A trace also gives context that metrics cannot. It may show the customer region, API route, deployment version, model name, cache result, or database statement category. Those attributes make one request explainable, provided they do not contain sensitive data and are controlled carefully.

The production pattern

A sensible production workflow is:

1. Alert on metrics and SLOs. Alert on error rate, latency distributions, request volume, saturation, queue age, or failed jobs. Saturation means how close a resource is to its usable capacity. These signals are aggregated, stable, and cheap enough to evaluate continuously.

2. Pivot from the alert to traces. A dashboard may provide a trace ID for a representative request, sometimes through an exemplar, which is a metric data point linked to a trace. Otherwise, filter traces by service, route, region, time window, and latency.

3. Inspect the critical path. Find the longest span and determine whether it represents computation, downstream latency, queue waiting, lock contention, retries, or network time.

4. Use logs for event detail. A log is a timestamped record such as “connection pool exhausted” or “payment request retried.” Logs explain what an operation reported; spans show where that operation sat in the request path. Including the trace ID and span ID in logs lets you move between the two.

5. Verify the fix with metrics. A single healthy trace does not prove the incident is over. Check the p95 or p99 latency, error rate, and affected-region breakdown across the fleet.

Instrumentation should exist at meaningful boundaries: incoming requests, outgoing HTTP or RPC calls, database operations, message publishing and consumption, cache calls, and model or tool invocations. A common instrumentation standard such as OpenTelemetry can create and export these signals, while a propagation standard such as W3C Trace Context carries the trace identity between services.

The nuance that earns the senior signal

Monitoring and tracing are complementary, not competing replacements.

“Monitoring” is sometimes used broadly to include dashboards, uptime checks, logs, traces, profiling, and alerting. In an interview, clarify that you are using the conventional distinction: monitoring primarily means aggregated health signals, while tracing means request-level causality and timing.

Tracing is also not automatically more accurate. It is usually more expensive because each request can produce many spans and attributes. Systems therefore sample traces, meaning they keep only some requests. Sampling reduces cost, but it can miss rare failures. A head sampler decides near the beginning of a request; a tail sampler waits until the trace is complete and can preferentially retain slow or error traces. Tail sampling is more useful for incident investigation, but it requires buffering and more complicated infrastructure.

Do not use traces as the only source for an availability SLO. A sampled trace store may contain no record of a particular failed request. Metrics can count every request at much lower cost and provide a reliable denominator.

There is another important limitation: a trace shows recorded relationships and timings, not proof of root cause. If an application waits 1.8 seconds for a database, the database may be slow because of a lock, a bad query plan, storage latency, or pressure elsewhere. The trace narrows the search. It does not perform the postmortem for you.

For a small, low-traffic monolith, detailed tracing of every internal function may not be worth the storage and operational cost. Start with service-level metrics and structured logs, then trace the boundaries where requests leave the process or where latency is difficult to explain. Conversely, in a microservice or agent system with retries, queues, model calls, and fan-out, tracing becomes much more valuable.

What they’ll ask next

Should we alert on traces?

Usually, alert on metrics derived from all traffic: error rate, latency, queue age, or an SLO burn rate. Use traces to investigate the alert. A trace backend can produce aggregate metrics, but alerting on the existence of one bad trace is noisy and can miss failures that were not sampled.

How do you trace asynchronous queues?

Create a producer span when the message is published and a consumer span when it is processed. Propagate the trace context in the message metadata, and measure queue waiting separately from processing time. For fan-out or fan-in workflows, span links may represent relationships where one operation has several relevant parents. Queue metrics remain essential because tracing one message does not reveal the age of every message waiting behind it.

What if the dashboard says p95 is slow but the traces look healthy?

Check for sampling bias first. The traces may represent only successful or fast requests. Then check whether the slow time is outside instrumented spans, such as load-balancer queuing, connection-pool waits, client-side retries, or an uninstrumented dependency. Also verify that the metric and trace filters use the same route, region, tenant, and time window. Many “tracing contradicts monitoring” incidents are actually mismatched populations.

Say this in the interview

“Monitoring aggregates fleet-wide health to detect and scope a problem, while distributed tracing follows one request through its spans to localize the delay or failure; I use metrics to trigger investigation, traces to explain it, and metrics again to verify the fix.”