Specify MeterProvider configurable cardinality limits#2960
Merged
Conversation
added 2 commits
November 17, 2022 16:07
reyang
reviewed
Nov 18, 2022
reyang
reviewed
Nov 18, 2022
jack-berg
reviewed
Nov 21, 2022
arminru
added
area:sdk
added 3 commits
November 28, 2022 09:48
…ication into jmacd/metrics_limits
jmacd
changed the title
Contributor
Author
|
This PR has been updated to specify the limit at the MeterProvider level. PTAL. |
pirgeo
reviewed
Nov 29, 2022
MrAlias
reviewed
Nov 29, 2022
Co-authored-by: Georg Pirklbauer <georg.pirklbauer@dynatrace.com>
Co-authored-by: Georg Pirklbauer <georg.pirklbauer@dynatrace.com>
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
added 3 commits
December 12, 2022 10:52
…ication into jmacd/metrics_limits
…-specification into jmacd/metrics_limits
jack-berg
approved these changes
Dec 13, 2022
Member
|
/easycla |
carlosalberto
approved these changes
Apr 24, 2023
Contributor
|
@open-telemetry/specs-approvers Please take a look at the latest iteration. This PR has been discussed/standing for a long time now, and would be great to have it adjusted/merged soon. |
alanwest
reviewed
Apr 24, 2023
pirgeo
approved these changes
Apr 25, 2023
alanwest
approved these changes
May 2, 2023
lzchen
approved these changes
May 2, 2023
Co-authored-by: Alan West <3676547+alanwest@users.noreply.github.com>
…ication into jmacd/metrics_limits
…-specification into jmacd/metrics_limits
Contributor
|
@jmacd Should we include this in the May release? |
Contributor
|
Talked to @jmacd, we are ready to roll this in. Thanks a lot for the iteration (and patience)! |
Open
4 tasks
This was referenced May 30, 2023
1 task
Closed
33 tasks
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this pull request
Oct 31, 2024
…#2960) Fixes open-telemetry#1891. **EDIT: Updated to specify cardinality limits at the View/Instrument level with a Reader-level default. Updated to use a hard limit** ## Changes Adds optional support for a maximum cardinality limit. The recommended default is 2000, based on this comment by open-telemetry#1891 (comment) @jack-berg. ~The Prometheus-WG SIG discussed this on Nov 9, 2022 and reached this recommended solution to the problem outlined in open-telemetry#1891. The consequence of exceeding these limits is in line with the current Prometheus server behavior, which drops targets that misbehave. The discussed was summarized here: open-telemetry#1891 (comment)
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
17 participants
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.
Fixes #1891.
EDIT: Updated to specify cardinality limits at the View/Instrument level with a Reader-level default. Updated to use a hard limit
Changes
Adds optional support for a maximum cardinality limit.
The recommended default is 2000, based on this comment by #1891 (comment) @jack-berg.
The Prometheus-WG SIG discussed this on Nov 9, 2022 and reached this recommended solution to the problem outlined in #1891. The consequence of exceeding these limits is in line with the current Prometheus server behavior, which drops targets that misbehave. The discussed was summarized here: #1891 (comment)