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

convert custom range to vmrange map #71

Conversation

AndrewChubatiuk
Copy link
Contributor

@AndrewChubatiuk AndrewChubatiuk commented Mar 6, 2024

Added ability to convert custom range to a map of vmrange -> count map pairs
Required for VictoriaMetrics/VictoriaMetrics#5855

@@ -57,6 +57,32 @@ type Histogram struct {
sum float64
}

// ConvertToVMRange distributes input value in a range (lower, upper] to a vmRange static buckets
func ConvertToVMRange(output map[string]float64, value, lower, upper float64) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand how this function is intended to be used. Could you add an example with it's usage?

As far as I understand, it's possible to create a new histogram, write value into it and use visit method:

var hs metrics.Histogram

hs.Update(value)
hs.VisitNonZeroBuckets()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Idea of a function is to convert prometheus histogram ranges to VMranges. In an input we have distribution of values in a range without exact values (that's why approach you've suggested doesn't work), so here I just dividing prometheus range proportionally into VM buckets, e.g.:
input range 2..8 contains value 6 and it should be placed into three ranges 0..3, 3..6 and 6..9. According to a logic of a function to a first output range it will put (3-2)/(8-2) * 6 = 1, to a second (6-3)/(8-2) * 6 = 3 and third (8-6)/(8-2) * 6 = 2

Copy link
Contributor

@hagen1778 hagen1778 May 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this function is here because it relies on many internal consts. The external caller can't possibly know about these costs, and neither can it assume these costs.
So the options are the following:

  1. Have this function, with a comment it is a helper function
  2. Expose internal consts, so the external caller could do the calculations on its own.
  3. Copy the consts to the caller codebase with assumption they won't ever change.

What do you think about this, @f41gh7 ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I'd prefer 3.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm ok with 3. @AndrewChubatiuk ?

@AndrewChubatiuk
Copy link
Contributor Author

implemented both native histograms and opentelemetry native histograms without conversion to static vm histograms ranges

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants