Unbounded memory growth in MeterListener when using high‑cardinality labels

Direct answer

There is no fixed cardinality threshold at which MeterListener starts consuming unbounded memory, because the listener itself does not cache or aggregate your measurements. Memory growth comes almost entirely from what your callback does with each unique tag combination. If your OnMeasurementRecorded handler stores every distinct TagList in a dictionary, memory grows linearly with the number of unique label values — there is no built-in cap, no automatic aggregation, and no eviction in System.Diagnostics.Metrics on .NET 7 or later.

Likely explanation vs. confirmed behavior

What is well established:

• Each unique combination of tag values passed to Counter.Add, Histogram.Record, etc. is delivered to the listener as a distinct measurement context. The runtime does not deduplicate or discard excess combinations for you.
• Histograms amplify the problem: if your callback keeps per-combination bucket state, every new label value allocates a full distribution structure, not just one counter.
• High-frequency recording of high-cardinality tags also creates GC pressure from repeated TagList allocations, even if you store nothing.

What remains uncertain and should be verified in your environment: whether any memory retention you observe comes from the listener pipeline itself or purely from your aggregation code. In practice, heap dumps in reported cases point at the developer's own storage collection, but treat this as a hypothesis until you dump your process.

Practical upper bound

Since no runtime limit exists, the safe bound is one you choose. A common working rule is to cap tracked tag combinations per instrument at a few thousand (for example 1,000–5,000), because each combination typically costs tens to hundreds of bytes in a dictionary plus per-histogram bucket state. Beyond that, aggregate the overflow into a single "other" bucket rather than dropping it silently.

Safe instrumentation pattern

1. Never use unbounded values as tags. User IDs, order IDs, GUIDs, timestamps, and full URLs are the classic offenders. Reduce them to bounded dimensions (status code class, route template, region).
2. Bound your callback storage. Use a fixed-size structure in the measurement callback — for example a dictionary guarded by a count check, or an LRU cache — and route everything past the cap into an overflow key:

listener.OnMeasurementRecorded = (instrument, value, tags, state) =>
{
    var key = tags.ToString(); // or a cheaper structural key
    if (!store.TryGetValue(key, out var entry))
    {
        if (store.Count >= MaxCombinations)
            key = "__overflow__";
        entry = store.GetOrAdd(key, _ => new AggregationEntry());
    }
    entry.Record(value);
};

1. Pre-aggregate at the source when possible. If you control the instrumentation, map raw values to a small enum or bucket before calling Record, so the cardinality never reaches the listener.

Verification

Confirm the diagnosis and the fix with two checks:

• Run dotnet-counters monitor --process-id <pid> and watch GC Heap Size and Gen 2 collections while recording metrics with deliberately unique tag values. Unbounded growth in the heap that tracks your unique-value rate confirms callback storage is the culprit.
• Capture a dump with dotnet-dump collect -p <pid> and inspect the dominant retained objects. If your dictionary or histogram-bucket types dominate, the retention is in your aggregation code, not the listener.
• After adding the cap, repeat the load and confirm the heap plateaus once the combination limit is reached.

Caveats

This guidance assumes .NET 7+ with System.Diagnostics.Metrics and a custom MeterListener. If you export via OpenTelemetry instead, the SDK's aggregation and cardinality handling differ and should be checked against its current documentation. If your heap dump shows retention inside runtime types rather than your own collections, that would change the recommendation — share the dump's dominant-type list before tuning further.