Labels & Series

A series is a unique combination of (metric_name, label_set):

http_requests_total{method="GET", path="/api", host="ip-10-0-1-23"}
http_requests_total{method="POST", path="/api", host="ip-10-0-1-23"}
http_requests_total{method="GET", path="/api", host="ip-10-0-1-24"}

Three series. Each has its own independent timeline.

Cardinality matters: each unique series = one storage chunk + index entry. Putting a high-cardinality value (request_id, user_id, full URL) as a label can blow up cardinality from thousands → millions → out-of-memory.

GOOD labels: host, method, status, environment, region
BAD labels: user_id, request_id, full URL with query params

Series ID: deterministic hash of (metric + sorted labels):

The same series across processes maps to the same ID — letting distributed systems shard consistently.

Inverted index:

• For each label key=value, the set of matching series IDs.
• Query "host=h1 AND service=api" = intersect two sets → matching series.

Cardinality estimation: HyperLogLog probabilistically counts distinct series with bounded memory. Used for capacity planning.

Series churn: container/pod restarts create new series IDs (new pod_uid label). Long-running series die; new ones born. Storage must cope with high series turnover.

Limits in production:

• Prometheus: ~5M active series per instance manageable.
• VictoriaMetrics: 100M+ on a single node (denser indexing).
• Long-tail series problem: many series with very few points.