Metrics

Metrics are numeric measurements collected at regular intervals — CPU usage, request latency, queue depth, error counts. Each metric is typically a time series: a sequence of timestamped values, often tagged with labels (service=checkout, region=eu-west-1) that let you slice and aggregate the data.

Metrics are the cheapest of the observability pillars to store and query at scale, which is why they’re usually the first line of defense: dashboards for humans, and threshold- or anomaly-based rules for alerting.

Why metrics matter

• Cheap and fast at scale. A counter or gauge takes a fixed amount of storage regardless of how much underlying activity it represents, unlike logs or traces which grow with request volume.
• Great for trends and alerting. Metrics answer “is this getting worse over time?” and “should someone be paged right now?” better than any other signal.
• Foundation for SLOs. Error rates and latency percentiles derived from metrics are the standard inputs for service level objectives and error budgets.

Key concepts

• Counters, gauges, histograms, summaries. The four core metric types: a counter only goes up (requests served), a gauge can go up or down (memory in use), and histograms/summaries capture distributions (request latency buckets).
• Cardinality. The number of unique label combinations a metric can produce. High-cardinality labels (like raw user IDs) can overwhelm a metrics backend — this is the single most common production incident with metrics systems.
• RED and USE methods. Two popular frameworks for deciding what to measure: RED (Rate, Errors, Duration) for request-driven services, and USE (Utilization, Saturation, Errors) for resources like CPU, disk, and memory.
• Pull vs. push. Prometheus popularized a pull model (the server scrapes targets); many managed platforms use a push model instead (agents ship metrics outward).

Where metrics fit with the other pillars

Metrics tell you that something is wrong and roughly where. Traces then show you the exact path a slow or failing request took, and logs give you the detailed, per-event context to explain why. Continuous profiling goes one level deeper, showing exactly which lines of code or functions consumed the CPU or memory behind a metric spike.