Time-Series Metrics

An SRE at a financial services company was reviewing dashboards on a Friday afternoon. She noticed a trend, memory usage across the API cluster had been creeping up by 2% per day for the past week. At the current rate, the servers would hit their memory limits by Monday morning, causing cascading OOM kills during peak traffic.

She filed a ticket, the team deployed a fix over the weekend, and Monday passed without incident. No outage. No pager. No emergency.

That prediction was only possible because the monitoring system stored metrics as time series, sequences of data points ordered by time. A single memory reading tells you "we're at 78% right now." A time series tells you "we were at 64% a week ago, 70% three days ago, 74% yesterday, and 78% today, and the trend is accelerating."

Time-series data is the foundation of every monitoring system you'll ever use. Prometheus, Datadog, Grafana, CloudWatch. They all store metrics as time series internally.

A time series is a sequence of (timestamp, value) pairs, identified by a metric name and a set of labels:

Metric: http_request_duration_seconds
Labels: {service="checkout", method="POST", status="200"}

Timestamp | Value
-----------------------|------
2026-04-04T10:00:00Z | 0.234
2026-04-04T10:00:15Z | 0.189
2026-04-04T10:00:30Z | 0.312
2026-04-04T10:00:45Z | 0.198
2026-04-04T10:01:00Z | 0.445

Each unique combination of metric name + labels creates a separate time series. This means http_requests_total{status="200"} and http_requests_total{status="500"} are two different time series, even though they share a metric name.

Time-Series Databases (TSDBs) are purpose-built for this data pattern. They're optimized for:

• High write throughput (thousands of data points per second)
• Time-range queries ("give me the last 6 hours")
• Aggregation over time windows ("average per minute")
• Data compression (consecutive timestamps compress extremely well)