Request-Level Tracing vs Aggregate Metric Dashboards

Two layers of observability, and why you need both

Observability has two layers that serve different purposes. Request-level traces record the fine detail of every individual call; aggregate metrics summarize those traces into the dashboard a team watches. Both are necessary, but they have different failure modes, and the understand-level insight here is that an aggregate dashboard, however healthy it looks, can hide a costly or broken minority of requests that only per-request decomposition reveals. Relying on aggregates alone is one of the most common observability blind spots.

Traces are the raw material

A request-level trace captures, for a single call, everything you might later need to understand it: which model and version ran, the input and output token counts, the latency, the stop reason, and any tool calls the request made. This is the ground truth, one record per request, preserving the detail that averages throw away. It is built directly on the four logging categories, and it is what makes any deeper investigation possible, because you cannot decompose a metric you never captured at the request level.

Aggregation summarizes them into a dashboard

Metric aggregation rolls those individual traces up into the numbers a team actually monitors: cost per request, latency at p50 and p95, task success rate (where a downstream acceptance signal exists), and error rate broken out by error type. Aggregation is genuinely useful, it turns millions of traces into a handful of watchable numbers, and it is how you see trends and catch broad shifts. The dashboard is the aggregate layer, and most day-to-day monitoring happens there.

The relationship is one-directional and important to keep straight: traces feed aggregates. The aggregate is only ever a summary of the underlying traces, which means anything the summary smooths over is still present in the traces but invisible on the dashboard.

The blind spot: a costly or broken minority

Here is the failure aggregate-only monitoring cannot catch. An average, or even a p95, can look perfectly healthy while a small fraction of requests behaves very differently from the rest, consuming most of the budget, or producing wrong outputs, without moving the aggregate enough to notice. A skewed cost distribution is the classic case: most requests are cheap, a few are enormous, and the mean cost per request looks fine while a handful of requests quietly eats the budget. The same is true of quality, a small class of inputs can be failing while the overall success rate stays high, because the failing minority is diluted by the passing majority.

Per-request decomposition is the defence. By breaking the metrics down, by request type, by input source, by user class, rather than viewing only the rolled-up number, you surface the minority that the aggregate hides. This is exactly why both layers are needed: aggregates catch the obvious, broad problems; per-request decomposition catches the non-obvious ones concentrated in a slice of traffic.

What the exam trips candidates on

The first trap is relying solely on an aggregate cost-per-request dashboard, missing a small subset of requests that consumes a disproportionate share of the budget. A scenario will show a healthy average cost while the bill climbs; the credited reading decomposes cost per request to find the expensive minority the average smoothed over.

The second trap is assuming a healthy-looking aggregate success rate means every request class is performing well, without decomposing by request type or input source. A scenario will present a high overall success rate; the correct answer breaks it down by class and finds a specific input type failing beneath the reassuring aggregate. Both traps reward remembering that the aggregate is a summary that hides its own minorities.

Common misreadings to avoid

How this shows up on the exam

Domain 4 questions on this knowledge point present a healthy aggregate, cost or success rate, alongside a symptom the aggregate does not explain. The reliable move is to recognize that aggregates hide minorities, and to decompose the metric per request, by type, source, or segment, so the costly or failing slice is surfaced.

This builds directly on the four logging categories, whose per-call records are the traces that aggregation rolls up. The hidden-minority reasoning is the observability twin of token distribution skew and the tail logic in p95 latency. It sets up anomaly detection and alerting, which watches these metrics for shifts, discernment, which judges the quality aggregates cannot, and the technical-to-business metric translation layer, which maps these metrics to stakeholder KPIs.