Practice the vocabulary of keeping a metrics system's storage and query cost from spiraling out of control.
0 / 5 completed
1 / 5
At standup, a dev mentions a metrics system's storage and query cost growing dramatically because a label, like a raw user ID, was attached to a metric and produced a huge number of distinct label-value combinations. What is this problem called?
Cardinality explosion is a metrics system's storage and query cost growing dramatically because a high-cardinality label, like a raw user ID, was attached to a metric and produced a huge number of distinct label-value combinations, each one stored as its own separate time series. A metrics system whose storage cost stays constant regardless of label combinations ignores how most time-series databases actually store and index a distinct series per unique label combination. This explosion is what makes attaching an unbounded-value label to a metric a costly mistake in practice.
2 / 5
During a design review, the team wants to avoid attaching a label whose possible values are effectively unbounded, like a raw user ID or a full request path, directly onto a metric. Which capability supports this?
Bounding label cardinality by choosing a label with a small, fixed set of possible values, like an HTTP status code or a small enum of request types, keeps the number of distinct time series manageable. Attaching a label with an effectively unbounded set of values, like a raw user ID, directly onto a metric produces a distinct time series per unique value, exactly the setup for a cardinality explosion. This deliberate bounding is the standard practice for keeping a metrics system's storage and query cost predictable.
3 / 5
In a code review, a dev notices a high-cardinality identifier that's genuinely useful for debugging is logged as a structured log field instead of being attached as a metric label. What does this represent?
Routing a high-cardinality identifier to a structured log field instead of a metric label preserves the identifier's genuine debugging usefulness without exploding the metrics system's time-series count, since a logging system is generally built to handle a much higher cardinality of distinct field values. Attaching that same identifier directly as a metric label produces a distinct time series per unique value, exactly the cardinality explosion this practice avoids. This routing decision is a common way to keep detailed, per-request context available without paying the metrics system's per-series cost for it.
4 / 5
An incident report shows a metrics backend's storage costs and query latency both spiked sharply after a new metric was shipped with a raw user ID attached as a label, generating millions of distinct time series almost overnight. What practice would prevent this?
Reviewing a new metric's proposed labels before shipping it, and removing any label with an effectively unbounded set of possible values like a raw user ID, prevents exactly the storage and latency spike this incident describes. Shipping a new metric with no review of its labels' potential cardinality is exactly what let millions of distinct time series appear almost overnight. This label review is a standard step in any team's process for introducing a new metric into a shared metrics backend.
5 / 5
During a PR review, a teammate asks why the team avoids attaching a raw user ID as a metric label instead of just letting the metrics backend handle whatever cardinality shows up. What is the reasoning?
A raw user ID has an effectively unbounded set of possible values, and most metrics backends store a distinct time series per unique label combination, so an unbounded label drives storage and query cost up dramatically as more distinct values appear. The tradeoff is that a genuinely useful, high-cardinality identifier still needs somewhere to live, which is usually a structured log field rather than a metric label, preserving its debugging value without the metrics system's per-series cost.