Don't Panic - Metrics Fundamentals

Metrics are the notebook a system keeps about itself, except the notebook contains numbers, timestamps, and no explanation of why the server began behaving like a startled goat. They turn repeated observations into time series, which makes the present comparable with the recent past. Before metrics, an operator often had a collection of individual events and guesses. Metrics provide the aggregate evidence needed to see rates, levels, and distributions.

The important bit is the question. A counter can show completed requests or errors. A gauge can show the current queue depth or memory level. A histogram can show how request duration is distributed, including whether work crosses a useful threshold. Pick a shape that matches the behavior, because asking a gauge to remember completed work is like asking a thermometer to keep the receipts.

Dimensions split a metric into meaningful groups. Method, status, and region can help compare behavior. User IDs, email addresses, request IDs, and random tokens create a fresh time series whenever they change. This is the surprise: a tiny label can become a large storage and query problem. Name one quantity and one unit, then keep only dimensions that support a decision.

Metrics are evidence, not a health verdict. A low CPU value does not prove that a request succeeded. Logs retain the detailed event, and traces follow one operation across component boundaries. When a graph changes, those signals explain the particular work behind the trend.

Open the Intro for the full model and the distinction between counters, gauges, histograms, and summaries. Use the Cheatsheet when designing names, units, buckets, and dimensions. The Field Notes describe the operational cost of a dimension that has not earned its place. The exercise turns all of that into a bounded metric contract, which is far less glamorous than a dashboard and considerably more useful.