-
Notifications
You must be signed in to change notification settings - Fork 880
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
Use metrics unit in user scope #2759
Conversation
@@ -104,7 +104,7 @@ type ( | |||
RecordTimer(timer string, d time.Duration) | |||
// RecordDistribution records a distribution (wrapper on top of timer) for the given | |||
// metric name | |||
RecordDistribution(id string, d int) |
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.
we really need to consolidate userScope with internal metric client.
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.
This will break OSS users existing implementation of custom metrics reporter I think? We need to call it out in the release notes if that's the case.
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.
Yes. We need to mention in the release note in 1.17
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.
currently, it is not possible to implement custom metrics reporter. because the people don't have access to internal metrics definition which is needed to implement that metrics.Client which takes a scopeId (int), and the implementation need to translate to string but cannot access those internal definition.
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.
we need to fix that as well.
@@ -323,6 +366,13 @@ func convertPrometheusConfigToTally( | |||
} | |||
} | |||
|
|||
func setDefaultPerUnitHistogramBoundaries(clientConfig *ClientConfig) { | |||
if clientConfig.PerUnitHistogramBoundaries != nil && len(clientConfig.PerUnitHistogramBoundaries) > 0 { |
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.
client config might have only overwrite one unit type
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 we should keep it backward compatible. So if there is partial customized boundaries, it will use the customized boundaries with defined unit and others fall back to the default boundaries.
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 don't think it will break anything. It just uses different bucket boundaries which should not break any metrics. The new ones in this PR is better than the old default one. For example bytes, the old default have buckets for 0.1 byte.
2000000 * ms, | ||
5000000 * ms, | ||
10000000 * ms, |
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 assume this is recent change after 1.16?
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.
Yes
@@ -104,7 +104,7 @@ type ( | |||
RecordTimer(timer string, d time.Duration) | |||
// RecordDistribution records a distribution (wrapper on top of timer) for the given | |||
// metric name | |||
RecordDistribution(id string, d int) |
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.
This will break OSS users existing implementation of custom metrics reporter I think? We need to call it out in the release notes if that's the case.
What changed?
Use metrics unit in user scope
Why?
The current user scope uses the default unify bucket and we should allow define metrics unit
How did you test it?
Potential risks
Is hotfix candidate?