Lexicon
Cardinality
Cardinality is the number of distinct values an attribute can take. Why it drives observability cost, how explosions happen, and what high cardinality buys.
Definition
Cardinality is the number of distinct values, or distinct value combinations, that an attribute or set of attributes can take. In observability it matters most for metrics, where every unique combination of attribute values creates its own time series to store and index.
What it means in observability
Cardinality is the hidden multiplier behind most surprising observability bills. A metric with a handful of labels looks innocent until the label values multiply: ten endpoints times five status codes times two hundred pods is ten thousand series from one metric name. Yet high cardinality is not a mistake, it is where the debugging value lives. The whole point of modern observability is asking questions like show me latency for this one customer, and that question requires a high cardinality attribute to exist.
How it works in practice
For metrics, series count is the product of each attribute's distinct values, which is why one unbounded label, a user ID, a request ID, a container hash, can explode a metric into millions of series. Time series databases degrade as series counts climb, and many vendors price by series or by custom metric, turning cardinality directly into money. Logs and traces tolerate high cardinality far better, since they store discrete events rather than one series per value combination, which is why the practical guidance is bounded attributes on metrics, rich attributes on spans and logs.
Where it gets hard
The failure modes come in two flavors. The explosion: a deploy adds one careless label and the metrics platform buckles, or the bill triples. The amputation: teams, trained by per series pricing, strip the identifying attributes from their telemetry until it is cheap and useless, and the question that would have solved the incident can no longer be asked.
Where Tsuga fits
Tsuga prices telemetry flat per GB rather than per series, per custom metric, or per host, so cardinality is an engineering consideration rather than a billing trap. Keep the attributes that answer questions; put high cardinality detail on spans and logs where it belongs.
Related terms
- APIAn API, or application programming interface, is the defined contract through which one piece of software talks to another.
- CounterA counter is a metric type for values that only accumulate: requests served, errors thrown, bytes transmitted, jobs completed.
- Elastic ObservabilityElastic offers observability built on the Elasticsearch stack: log search at its core, with metrics, traces, and APM layered on, available self managed or as the hosted Elastic Cloud.
- HistogramA histogram is a metric type that captures how values distribute, by counting observations into buckets, rather than recording what any single value was.
- Kubernetes monitoringKubernetes monitoring is observability applied to Kubernetes clusters: the nodes, workloads, pods, and containers that run modern applications, plus the control plane that orchestrates them.
- MetricA metric is a named numeric measurement tracked over time, request counts, memory usage, response latency, carrying a type, a unit, and attributes that slice it into series.
- SamplingSampling is the practice of keeping only a subset of telemetry, usually traces, so that volume and cost stay manageable.
- SpanA span is a single timed operation inside a trace: an HTTP request, a database call, a queue publish, or an internal step worth measuring.