Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: STREAM_CARDINALITY_LIMIT should be config #1951

Open
domyway opened this issue Jul 22, 2024 · 10 comments
Open

[Feature]: STREAM_CARDINALITY_LIMIT should be config #1951

domyway opened this issue Jul 22, 2024 · 10 comments
Assignees
Labels
enhancement New feature or request priority:p1 Critical issues and bugs. Highest priority. triage:todo Needs to be traiged.

Comments

@domyway
Copy link

domyway commented Jul 22, 2024

Related Problems?

No response

Describe the solution you'd like:

I got some warning log like :
OpenTelemetry metrics error occurred. Metrics error: Warning: Maximum data points for metric stream exceeded. Entry added to overflow.

I use histogram and it has many labels , I find the log code here:

pub(crate) fn is_under_cardinality_limit(size: usize) -> bool {
    size < STREAM_CARDINALITY_LIMIT as usize - 1
}

it should be config

Considered Alternatives

No response

Additional Context

No response

@domyway domyway added enhancement New feature or request triage:todo Needs to be traiged. labels Jul 22, 2024
@cijothomas cijothomas self-assigned this Jul 22, 2024
@cijothomas
Copy link
Member

Thanks for reporting this. We are aware of this #1065 can be used for tracking.
(This is a p0 before stable, and I expect to land this in upcoming release ~ 2 weeks out)

@domyway
Copy link
Author

domyway commented Aug 12, 2024

Thanks for reporting this. We are aware of this #1065 can be used for tracking. (This is a p0 before stable, and I expect to land this in upcoming release ~ 2 weeks out)

HI, How is it going~~

@cijothomas
Copy link
Member

Thanks for reporting this. We are aware of this #1065 can be used for tracking. (This is a p0 before stable, and I expect to land this in upcoming release ~ 2 weeks out)

HI, How is it going~~

Working through a major refactoring of the Metrics sdk! A lot has been done to fix perf issues, but not yet reached the stage where we have addressed this issue. Though it is delayed, it is still the top feature that must be added in my mind!

@cijothomas
Copy link
Member

Update:
The spec is still experimental (open-telemetry/opentelemetry-specification#3904), and no sign of moving it to stable in next few weeks.

I think its best to do the following for OTel Rust:

  1. Move the cardinality-capping under opt-in feature flag. i.e By default, there won't be cardinality capping.
  2. If opted-in, provide ability to customize the default cardinality on a MetricReader level. (i.e not on per metric level using Views.) This is because we are not 100% sure if Views can be part of 1st stable release or not.
  3. Once the spec is stable, remove feature-flag, and make this the default.
  4. At this point, provide ability to customize per metric.

If all agree to this, we can make this happen for 0.26 release (~<2 weeks)

@utpilla
Copy link
Contributor

utpilla commented Sep 19, 2024

Update: The spec is still experimental (open-telemetry/opentelemetry-specification#3904), and no sign of moving it to stable in next few weeks.

I think its best to do the following for OTel Rust:

  1. Move the cardinality-capping under opt-in feature flag. i.e By default, there won't be cardinality capping.
  2. If opted-in, provide ability to customize the default cardinality on a MetricReader level. (i.e not on per metric level using Views.) This is because we are not 100% sure if Views can be part of 1st stable release or not.
  3. Once the spec is stable, remove feature-flag, and make this the default.
  4. At this point, provide ability to customize per metric.

If all agree to this, we can make this happen for 0.26 release (~<2 weeks)

That sounds reasonable.

@cijothomas
Copy link
Member

There is some movement in spec, so will check the spec status and re-update here:
open-telemetry/opentelemetry-specification#4222

@cijothomas
Copy link
Member

There is some movement in spec, so will check the spec status and re-update here: open-telemetry/opentelemetry-specification#4222

The spec is stable, I change my position about this. Here's the new proposal

  1. Do this by default (no feature flags required as the spec is already stable)
  2. Keep the configuration at Reader level.
  3. Do not offer View based config to control cardinality per metric in the initial release, consider Views feature itself might not be part of 1.0
  4. Add 3 post 1.0.

@cijothomas cijothomas added this to the 0.27 milestone Oct 8, 2024
@cijothomas
Copy link
Member

1,2,4 will be added in 0.27.1 milestone. Its additive change only, and we are about to declare the Metrics API as RC tomorow, so this got lower priority.
0.27.1 is coming in < 2 weeks, so not that far out.

@cijothomas cijothomas modified the milestones: 0.27, 0.27.1 Nov 8, 2024
@cijothomas cijothomas removed this from the 0.27.1 milestone Dec 2, 2024
@frittentheke
Copy link

frittentheke commented Dec 12, 2024

The now stable spec (https://github.com/open-telemetry/opentelemetry-specification/blob/v1.39.0/specification/metrics/sdk.md#cardinality-limits) now says that:

SDKs SHOULD support being configured with a cardinality limit.

I totally understand that this is already accepted as a feature in general and tracked also via #1065.

But @cijothomas since you removed the target milestone, could you kindly give a update if the capability to configure the cardinality limit would be targeting milestone 0.28 then or when it could be expected?

@cijothomas
Copy link
Member

@frittentheke Thanks for calling this out. Yes this is a miss from my side. I just added it to Metric SDK stable milestone, but hopefully we can do it in 0.28 itself.

This is not only an important gap, but a blocker from going stable.

@cijothomas cijothomas added the priority:p1 Critical issues and bugs. Highest priority. label Dec 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request priority:p1 Critical issues and bugs. Highest priority. triage:todo Needs to be traiged.
Projects
None yet
Development

No branches or pull requests

4 participants