Some users (e.g. #3308 (comment)) have legitimate use cases where they know the cardinality of a metric exactly and want the SDK to store all data points without overflow attribution.
Today, every metric stream has a cardinality limit (default 2000, configurable via views). There is no way to opt out.
The OpenTelemetry specification treats cardinality capping as a SHOULD, not a MUST, so there is room for the SDK to offer an opt-out. Combined with the genuine user need above, providing an explicit opt-in to disable the cap seems reasonable.
This issue tracks adding such an API to disable the cardinality limit on a metric stream. The API name and ergonomics should make clear that this is an advanced choice (e.g. with_cardinality_limit_disabled() or similar) and that disabling is a deliberate decision the user takes responsibility for.
Related: #3290, #3308
Some users (e.g. #3308 (comment)) have legitimate use cases where they know the cardinality of a metric exactly and want the SDK to store all data points without overflow attribution.
Today, every metric stream has a cardinality limit (default 2000, configurable via views). There is no way to opt out.
The OpenTelemetry specification treats cardinality capping as a SHOULD, not a MUST, so there is room for the SDK to offer an opt-out. Combined with the genuine user need above, providing an explicit opt-in to disable the cap seems reasonable.
This issue tracks adding such an API to disable the cardinality limit on a metric stream. The API name and ergonomics should make clear that this is an advanced choice (e.g.
with_cardinality_limit_disabled()or similar) and that disabling is a deliberate decision the user takes responsibility for.Related: #3290, #3308