Module 8 of 16
Observability
The mechanics behind telemetry at scale: metric types and cardinality, histogram error, traces and profiles, sampling and its cost, alert delays, and the signals that matter on GPU fleets.
Observability signals introduced metrics, traces, and logs, and showed how averages and coarse buckets mislead. This module covers how those signals are built and what they cost. It starts with metric types, histogram and summary error, and the arithmetic of cardinality, then moves to reading traces and sampling profilers. After that come sampling strategies, the telemetry bill, and the delays between a failure and a page, and the module ends with what to measure on GPU and inference fleets, where the standard gauges are the most misleading.
Afterward you should be able to look at a metric, a trace store, or a GPU dashboard and say what it can and cannot tell you, how wrong it can be, and what it will cost to keep.
Lessons
- 8.aMetrics, cardinality, and histogramsHow do metric types, label cardinality, and histogram buckets decide what a metric costs and how wrong its percentiles can be?16 min
- 8.bTracing and profilingHow do you find where a slow request spent its time, and which code is using the CPU, without being misled by the tools?17 min
- 8.cSampling, cost, and alertingHow do you keep telemetry affordable without losing the events that matter, and how long does an alert really take to fire?16 min
- 8.dObserving AI infrastructureWhich signals show what a GPU fleet is really doing, and how do you derive tokens per joule, cost per token, and MFU from raw counters?18 min