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.
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
Add capability to have configurable aggregation temporality for OTLP Registry #3625
Add capability to have configurable aggregation temporality for OTLP Registry #3625
Changes from 1 commit
5615949
2212f84
d8e4ee8
2664f89
7854a88
487af47
a83564a
dc2dd6b
8b8c350
490b2a3
6d9f226
cfd491f
2076bb2
65831a8
789b82b
08e43c2
8f51093
7d1cf36
95cb710
0db0221
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necessarily related to this PR, and might be addressed in a follow-up (also untested, I just happen to have fixed a similar bug recently): the fact that
super.takeSnapshot()
andmonotonicBucketCountHistogram.takeSnapshot()
are not synchronized might lead to discrepancies between the count and the bucket counts if some other thread records data in the time between the two method calls.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% sure that this is a good idea but this class seem the same as
OtlpCumulativeDistributionSummary
except:TimeWindowFixedBoundaryHistogram
/DistributionStatisticConfig
/etc. are created differentlygetStartTimeNanos
So I was thinking if we should have the common logic in a common place, e.g.:
OtlpDistributionSummary
that can handle both (getStartTimeNanos
will be there in the step case too).TimeWindowFixedBoundaryHistogram
/DistributionStatisticConfig
/etc. for example in ctor.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think
OtlpStepTimer
has the same situation.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's right see one of my TODOs in the PR description. This was one of my POC codes and it needs some re-designing and better code re-organization. Will start on that part and welcome any suggestions there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to ping us if you need some help.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. I might need some especially in restructuring some of these classes. Already, OtlpMeterRegisrty does what I believe was not How registries were meant to work doing 2 things - Step and Cumulative. And the same goes with the Timers and DistributionSummaries because there are different things inherently - Step and Cumulative. So, any help on this would be helpful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to throw in the idea of get-and-reset semantics for Histograms. Basically, you record the data, snapshot it, and then reset the histogram on every export. This circumvents the whole timer and rotation code, which I am not sure is required for a delta-based export. Just leaving this here as an idea, let me know if there is something I am missing