Aggregate Metrics vs Per-Request Decomposition

Why a healthy dashboard can lie

Once you are logging the four layers, the next question is how to look at the data, and the exam's warning is that aggregate metrics alone can mislead you badly. A dashboard showing mean cost and mean latency within range feels like proof the system is healthy. It is not, because an average smooths over the distribution. A small fraction of requests can be consuming most of the budget or producing wrong outputs, and the mean will still look fine, because the many healthy requests dilute the few pathological ones into invisibility. The dashboard is green while a real problem runs underneath it.

The resolution is not to abandon aggregates but to pair them with per-request decomposition: looking at the underlying requests, not just their summary statistics. This is the same tail-versus-average logic that makes p95 the right latency target, generalised from latency to cost and correctness.

Aggregates for trends, per-request for root cause

The two views do different jobs, and neither replaces the other. Aggregates are for trends: is cost rising week over week, is latency creeping up, is the error rate stable? They answer 'how is the system doing overall' and they are the right tool for spotting broad movement. Per-request decomposition is for root cause: which specific requests are expensive, which produced the wrong output, what do those requests have in common? It answers 'what exactly is going wrong and where.'

Try to run on aggregates alone and you see movement without cause; try to run on per-request data alone and you drown in detail without a sense of trend. The observability design the exam wants combines them: aggregates surface that something moved, and per-request decomposition explains what and why. This division also mirrors change attribution, where a moved aggregate metric still needs per-request detail to assign a cause.

Two failures aggregates hide

Two concrete failure shapes hide behind healthy averages, and both matter for the exam. The first is cost concentration: a skewed distribution where a small share of long or complex requests consumes most of the budget. The mean cost per request looks affordable, but total spend is dominated by a tail the average conceals, exactly the skewed-token-distribution problem seen in the observability data. The second is quiet incorrectness: a low overall error rate coexisting with outputs that are wrong but never errored. A 0.5% error rate says nothing about the successful-looking responses that are subtly incorrect, because those never counted as errors at all.

Both failures share a property: they are invisible in the aggregate and visible in the per-request data. That is precisely why per-request decomposition is non-optional. It is the only view in which the hidden fraction becomes a specific, investigable set of requests.

What the exam trips candidates on

Two traps. The first is declaring a system healthy because the dashboard's average metrics are within range, without checking the underlying distribution, which is trusting the aggregate to see what it structurally cannot. The second is assuming a low overall error rate means there are no quietly incorrect outputs, which confuses 'did not error' with 'was correct.' The credited answer pairs aggregates with per-request decomposition and treats a healthy average as necessary but not sufficient.

Common misreadings to avoid

How this shows up on the exam

Expect a scenario where a green dashboard coexists with an over-budget bill or a stream of wrong outputs, and a question about why the metrics missed it. The reliable reading is that aggregates hide the pathological fraction and per-request decomposition is required alongside them. This knowledge point builds on the four-layer logging model, shares its logic with p95 latency, and unlocks anomaly detection thresholds and model drift.