Unbounded memory growth in MeterListener when using high‑cardinality labels

Goal: establish a practical upper bound for the number of distinct label values that a MeterListener can safely handle before its internal storage grows without bound.

Constraints: the guidance applies to .NET 7 and later when using System.Diagnostics.Metrics with a MeterListener that collects histograms or counters; the runtime does not currently document a cardinality limit, and enabling high‑frequency collection may exacerbate memory pressure. Uncertainty remains whether the MeterListener automatically aggregates or discards excess label combinations, or if developers must implement their own sampling.

What label‑cardinality threshold triggers noticeable memory growth in a MeterListener session? Are there built‑in mechanisms to limit or aggregate high‑dimensional label sets? How can developers instrument high‑cardinality metrics safely without risking unbounded memory consumption?