Wire per-component cardinality limits from Config

[dougqh]

What Does This Do

Adds the ability to configure cardinality limits per component / tag for client-side stats

Motivation

Avoid problems with high cardinality leading to excessive resource consumption while informing the customer (via sentinel value) when a limit was reached

Additional Notes

Unlike #11387 which introduced the limiting mechanism, this PR enables the limits by default.

• Adds a single parameterized Config.getTraceStatsCardinalityLimit(tagName, defaultLimit) method following the RFC naming pattern DD_TRACE_STATS_{tag_name}_CARDINALITY_LIMIT
• Wires all 9 per-field PropertyCardinalityHandler instances and the TagCardinalityHandler in PeerTagSchema to read their limits from Config at class-load time, with defaults from MetricCardinalityLimits
• Activates sentinel substitution (useBlockedSentinel = true) now that limits are configurable; previously hardcoded to false pending this wiring
• Registers all 10 config keys in supported-configurations.json

Stacked on #11387.

Test plan

• Existing CardinalityHandlerTest and AggregateEntryTest cover sentinel substitution behavior
• Verify default limits match MetricCardinalityLimits constants
• Confirm DD_TRACE_STATS_RESOURCE_CARDINALITY_LIMIT etc. are picked up at startup via Config

tag: no release note
tag: ai generated

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 75f72165fd

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Validate stats cardinality limits before returning them

When any of the new DD_TRACE_STATS_*_CARDINALITY_LIMIT values is set to 0, a negative number, or a value above 2^29, this method returns it unchanged; the callers added in AggregateEntry and PeerTagSchema pass it directly into PropertyCardinalityHandler/TagCardinalityHandler, whose constructors throw for those ranges. In that misconfigured environment the stats classes fail initialization instead of falling back to the default/logging, so the accessor should reject invalid limits before handing them to the handlers.

Useful? React with 👍 / 👎.

[dougqh]

In my ideal world, config would probably handle this and report a warning immediately at start-up.
Unfortunately, there's no precedence for that in config today.
I'm in full agreement with the sentiment, but I think that's better left to another PR.

[chatgpt-codex-connector]

Use int for the new config metadata type

The supported-configurations metadata uses type: "int" for the existing integral settings (including the tracer metrics limits), while these ten new cardinality entries are the only ones using "integer". The local supported-configurations validation/publishing jobs consume this file, so the new configs can be rejected or omitted by downstream metadata consumers even though the agent code reads integers; please use int consistently for these entries.

Useful? React with 👍 / 👎.

[mhlidd]

Yup, int is used instead of integer in the file.

[AlexeyKuznetsov-DD]

@mhlidd WDYT to add a test that will check types and failed if there someone made a typo?
OR probably we can support some sort of aliases like int, integer should be treated as the same type...
But I like the test better.

[dougqh]

No need for aliasing, I'll just fix it. I'm curious why Claude decided to use the wrong value though.

[AlexeyKuznetsov-DD]

Yep, Just thinking how to prevent issues in future.
Fir example if there will be a test - Claude with high probability will run it, test will fail, Claude will fix it.

I'm curious why Claude decided to use the wrong value though.

I think it is a nature of LLMs, somehow integer has a bigger weight in model that int and LLM produced wrong output.

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	14.06 s	13.93 s	[-0.2%; +2.0%] (no difference)
startup:insecure-bank:tracing:Agent	12.93 s	12.97 s	[-1.0%; +0.5%] (no difference)
startup:petclinic:appsec:Agent	16.91 s	16.91 s	[-0.8%; +0.9%] (no difference)
startup:petclinic:iast:Agent	16.95 s	17.02 s	[-1.2%; +0.4%] (no difference)
startup:petclinic:profiling:Agent	16.80 s	16.87 s	[-1.4%; +0.5%] (no difference)
startup:petclinic:sca:Agent	16.95 s	16.76 s	[+0.1%; +2.2%] (maybe worse)
startup:petclinic:tracing:Agent	15.63 s	16.20 s	[-7.7%; +0.7%] (no difference)

Commit: e558d99c · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

[AlexeyKuznetsov-DD]

LGTM, but:

1. Code like:

Config.get()
                  .getTraceStatsCardinalityLimit(
                      "peer_tag", MetricCardinalityLimits.PEER_TAG_VALUE))

looks a bit noisy, probably can be improved if refactored to enum?
2. JSON descriptor should be fixed integer -> int.

[AlexeyKuznetsov-DD]

QQ: just curious if this MetricCardinalityLimits can be an enum and no need to pass string and int const. Just enum and get the rest from it where needed.

[dougqh]

Yeah, we might be able to do that. The only complication is that we might have to move the enum next to Config.

[dd-octo-sts]

Hi! 👋 Thanks for your pull request! 🎉

To help us review it, please make sure to:

• Add at least one type, and one component or instrumentation label to the pull request

If you need help, please check our contributing guidelines.