Metrics & Traces
A track of P37 · Observability — Logging, Metrics & Traces.
The other two pillars: build a metrics registry (counters, gauges, histograms) and instrument a request pipeline with trace spans to see where the time actually goes - logs vs metrics vs traces, and when to reach for each.
Logs are one pillar of observability; this track builds the other two. Metrics
are the cheap, always-on aggregates you dashboard and alert on — and the track has
you implement the three instruments that produce them: a counter (monotonic, so
you read a rate), a gauge (a level that moves up and down), and a histogram
(a distribution, so you get counts, sums and the percentiles a mean would hide). You
wrap them in a registry with a scrape() snapshot — the point-in-time reading a
real monitoring system pulls.
Traces are the third pillar, and the one that answers a question metrics can't: for this one request, where did the time go? A trace is a tree of spans — a root per request, a child per stage — and the track has you instrument the AdvP-002 request-pipeline simulator and read its span tree: the waterfall of stage names, each stage's injected duration, and the slowest stage. The simulator runs on a logical clock, so the whole trace is deterministic — you grade on structure, not wall-clock time.
Throughout, the framing is which pillar answers which question — logs for events, metrics for aggregates, traces for causality — plus the traps that bite in practice (RED/USE coverage, and keeping high-cardinality identifiers out of metric labels). The tracing idea links straight into P13's operations/monitoring for ML systems.