Metrics, Logs, and Traces
What the exam tests
Metrics, Logs, and Traces tests data-model fluency: instrument types, aggregation, correlation, sampling, and storage trade-offs across the three pillars.
Core rules
- Prometheus metric types: counter is monotonic; gauge is arbitrary; histogram exposes buckets plus _sum and _count; summary exposes client-side quantiles. OpenTelemetry instruments include counter, updowncounter, histogram, and observable variants.
- Histograms aggregate across instances; summaries cannot be merged correctly. Use native histograms or exponential buckets for broad latency ranges.
- Logs should be structured with timestamp, severity, message, resource, trace_id, and span_id. Avoid high-cardinality fields as index labels.
- A trace is a DAG of spans. Each span has trace_id, span_id, parent_span_id, name, start/end time, attributes, events, and status. Context propagation uses W3C traceparent and tracestate.
- Head sampling decides at trace start and is cheap but may miss rare errors. Tail sampling decides after spans arrive and can keep errors or slow traces, but requires all spans for a trace at one decision point.
- Exemplars link metrics to trace IDs, enabling a jump from a latency bucket to a sample trace.
Worked example
A latency histogram has cumulative bucket counts: le 100 ms = 800, le 200 ms = 900, le 500 ms = 980, le 1000 ms = 1000. The p95 rank is 950. It falls in the 200-500 ms bucket because 900 < 950 <= 980. Interpolate: 200 + ((950 - 900) / (980 - 900)) * (500 - 200) = 200 + 0.625 * 300 = 387.5 ms. The estimate is approximate because bucket width limits precision. Never average per-instance p99 values; average distributions or compute the quantile from merged buckets.
Traps
Summaries cannot be aggregated across pods. Missing units cause factor-of-1000 errors. Putting user IDs or URLs into log labels or metric labels explodes cardinality. Tail sampling without trace-affinity scatters spans and loses traces.