Metrics

Technical Definition

A metric is a time-series measurement: a named value, typically tagged with labels or dimensions, sampled or aggregated at regular intervals and stored for query and alerting. Common metric types include counters (monotonically increasing totals, such as request counts), gauges (point-in-time values, such as queue depth), and histograms or summaries (distributions, such as request latency percentiles). Metrics are distinct from logs, which are discrete event records, and from traces, which capture the path of an individual request through a system.

Operational Relevance

Metrics underpin alerting, capacity planning and incident response. Service level indicators (SLIs) such as error rate and latency are usually derived from metrics, and service level objectives (SLOs) define acceptable thresholds against them. Effective use depends on choosing cardinality carefully: unbounded label values (for example, embedding a user ID as a metric label) can overwhelm a metrics backend’s storage and query performance.

Architecture Relationship

Metrics are typically produced by application or infrastructure instrumentation, collected by an agent or exposed via a scrape endpoint, stored in a time-series database, and visualised or alerted on through a dashboard or alerting layer. This pipeline sits alongside, and is usually correlated with, logging and tracing systems as part of a broader observability architecture.

Example

A web service exposes a counter named http_requests_total with labels for HTTP method and status code, and a histogram named http_request_duration_seconds. A monitoring system scrapes these values periodically, and an alert rule fires if the rate of 5xx responses exceeds a defined threshold over a rolling window.

Common Misunderstanding

Metrics are often mistaken for a complete substitute for logs or traces. In practice, a metric tells you that a problem exists and roughly its scale, but it cannot by itself explain why a specific request failed; that context typically requires correlated log entries or a trace. Treating metrics as sufficient evidence for root cause, without corroborating detail, is a common source of misdiagnosis.

Related Terms

• Observability
• Time-series database
• Service level indicator (SLI)
• Service level objective (SLO)
• Logging
• Tracing

Further Reading and Validation

Before relying on a new or changed metric in production alerting, validate it in a non-production or isolated environment: confirm the metric is emitted with the expected name, labels and type, confirm the collection interval and retention meet the intended use, and confirm any alert rule built on it fires and clears correctly against a controlled test signal. If a metric definition is later changed or removed, keep the prior definition and any dependent dashboards or alerts available until the replacement has been validated, so that monitoring coverage is not silently lost during the transition.