enhancement(tag_cardinality_limit transform): A setting for per-metric vs global tag cardinality tracking#25372
Open
ArunPiduguDD wants to merge 1 commit intomasterfrom
Open
Conversation
tracking_scope setting f…
Open
9 tasks
…or per-metric vs global tag tracking When metrics do not have an explicit `per_metric_limits` entry, their tag values were always pooled into a single shared bucket. The new `tracking_scope` setting lets users opt into per-metric tracking buckets instead, providing isolation at the cost of higher memory. Default is `global` (current behavior); `per_metric` gives every distinct (namespace, name) its own bucket regardless of `per_metric_limits` membership. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
8044081 to
9a136f2
Compare
brett0000FF
approved these changes
May 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When metrics do not have an explicit
per_metric_limitsentry, their tag values were always pooled into a single shared bucket. This can lead to some of the following example scenarios:metric1andmetric2have thehosttag, butmetric1has a high cardinality for thehosttag (above the limit), thehosttag will be dropped onmetric2(even if the tag onmetric2only has 1-2 cardinality)host tag, and each tag has 1-2 unique values per metric, then a cardinality limit of 50 will drop this tag across all metrics.The new
tracking_scopesetting lets users opt into per-metric tracking buckets instead, providing isolation at the cost of higher memory.Default is
global(current behavior);per_metricgives every distinct (namespace, name) its own bucket regardless ofper_metric_limitsmembership.Vector configuration
How did you test this PR?
Tested with above configuration. Simulated an Otel Collector with the following Python script:
Change Type
Is this a breaking change?
Does this PR include user facing changes?
no-changeloglabel to this PR.References
Notes
@vectordotdev/vectorto reach out to us regarding this PR.pre-pushhook, please see this template.make fmtmake check-clippy(if there are failures it's possible some of them can be fixed withmake clippy-fix)make testgit merge origin masterandgit push.Cargo.lock), pleaserun
make build-licensesto regenerate the license inventory and commit the changes (if any). More details on the dd-rust-license-tool.