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

output/cloudv2: Trend as Histogram #3027

Merged
merged 11 commits into from May 30, 2023
Merged

output/cloudv2: Trend as Histogram #3027

merged 11 commits into from May 30, 2023

Conversation

codebien
Copy link
Collaborator

@codebien codebien commented Apr 20, 2023

Custom Histogram representation of the Trend metric type. It is the porting of the Histogram generation on the client side.

@codebien codebien added this to the v0.45.0 milestone Apr 20, 2023
@codebien codebien requested a review from artych April 20, 2023 16:37
@codebien codebien self-assigned this Apr 20, 2023
@codecov-commenter
Copy link

codecov-commenter commented Apr 21, 2023

Codecov Report

Merging #3027 (fbf36a1) into master (31d9302) will increase coverage by 0.10%.
The diff coverage is 91.02%.

❗ Current head fbf36a1 differs from pull request most recent head f764955. Consider uploading reports for the commit f764955 to get more accurate results

@@            Coverage Diff             @@
##           master    #3027      +/-   ##
==========================================
+ Coverage   73.57%   73.68%   +0.10%     
==========================================
  Files         240      241       +1     
  Lines       18364    18436      +72     
==========================================
+ Hits        13512    13585      +73     
+ Misses       3980     3978       -2     
- Partials      872      873       +1     
Flag Coverage Δ
ubuntu 73.68% <91.02%> (+0.10%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
output/cloud/expv2/mapping.go 40.84% <0.00%> (+0.56%) ⬆️
output/cloud/expv2/sink.go 100.00% <ø> (+50.00%) ⬆️
output/cloud/expv2/hdr.go 93.42% <93.42%> (ø)

... and 1 file with indirect coverage changes

@codebien codebien force-pushed the ingestion/binary-proto branch 2 times, most recently from 8396f62 to d7df637 Compare April 21, 2023 16:43
@codebien codebien force-pushed the ingestion/histogram branch 2 times, most recently from 63df8df to fb719c9 Compare April 24, 2023 15:01
@codebien codebien changed the title output/cloud: Trend as Histogram output/cloudv2: Trend as Histogram Apr 24, 2023
@codebien codebien marked this pull request as ready for review April 24, 2023 15:03
@codebien codebien requested a review from na-- April 24, 2023 15:04
output/cloud/expv2/hdr.go Outdated Show resolved Hide resolved
output/cloud/expv2/hdr.go Outdated Show resolved Hide resolved
output/cloud/expv2/output.go Outdated Show resolved Hide resolved
output/cloud/expv2/hdr.go Outdated Show resolved Hide resolved
// let n = msb(u) - most significant digit position
// i.e. n = floor(log(u, 2))
// major_bucket_index = n - k + 1
// sub_bucket_index = u>>(n - k) - (1<<k)
Copy link
Member

@na-- na-- May 18, 2023

Choose a reason for hiding this comment

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

Adding this mostly as a reminder to myself to double-check next week, since I don't immediately understand this line - why can sub_bucket_index be calculated like this? 🤔

The nth bucket contains [2^(n-1) : 2^n] values, equally divided in 2^k sub-buckets, right? So, I'd expect something like "zero out up to the nth bit to get the part of the number that needs to be divided into sub-buckets, divide it by 2^k to get the sub-bucket index".

But I'm probably missing something stupid, so if you have an explanation handy, please add it to the comment

@codebien codebien force-pushed the ingestion/binary-proto branch 2 times, most recently from b3821f5 to 46f3fdf Compare May 21, 2023 18:02
Comment on lines +13 to +28
const (
// lowestTrackable represents the minimum value that the histogram tracks.
// Essentially, it excludes negative numbers.
// Most of metrics tracked by histograms are durations
// where we don't expect negative numbers.
//
// In the future, we may expand and include them,
// probably after https://github.com/grafana/k6/issues/763.
lowestTrackable = 0

// highestTrackable represents the maximum
// value that the histogram is able to track with high accuracy (0.1% of error).
// It should be a high enough
// and rationale value for the k6 context; 2^30 = 1_073_741_824
highestTrackable = 1 << 30
)
Copy link
Collaborator

Choose a reason for hiding this comment

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

This IMO should be very well communicated and documented somewhere as I am not certain these were restrictions so far.

I doubt that many users use that big values or negative ones.

Is there a reason why we are removing negative values to begin with? As in this algorithm just does not work with them?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I would also link the algorithm used in:

  1. the code
  2. the commit
  3. the PR
  4. (likely) the docs when they are added

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Is there a reason why we are removing negative values to begin with? As in this algorithm just does not work with them?

My understanding of the original design is we did it with the assumption that most of the time we measure duration, and they are not negative. So it simplified the requirement for the algorithm.

output/cloud/expv2/hdr.go Outdated Show resolved Hide resolved
Comment on lines 125 to 132
if index < h.FirstNotZeroBucket {
h.growLeft(index)
h.FirstNotZeroBucket = index
}
if index > h.LastNotZeroBucket {
h.growRight(index)
h.LastNotZeroBucket = index
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Very likely for a future optimization:

For every given timeseries this bucket will likely just be recreated each bucket. This can potentially mean many allocations of slices over and over again across all time series for the whole duration of the test.

There are quite a few possibilities to mitigate this:

  1. obviously do nothing and see how it goes :)
  2. reuse the same histogram and all of its' buckets. This likely will be easier if histogramAsProto is called when the metrics are flushed and the whole instance is just set for the next bucket after it ... this seems very iffy to me.
  3. On each creation of a new histogram we can check if the previous bucket has a histogram for the same timeseries - copy its buckets (without the values obviously). This likely will be easier and we only pay the costs when a new histogram is added.
  4. something else that I forgot while typing :(
  5. Something else we come up with

I will expect this is a common problem so maybe someone has already solved it in the golang space.

The hdrhistogram-go repo has Snapshot (and a much bigger Histogram) which seems like a way to get values (snapshot) for some time and then continue to aggregate without needing to create the buckets from scratch.

Although in their case it is just a continues aggregation while we want to reset.

output/cloud/expv2/hdr.go Outdated Show resolved Hide resolved
output/cloud/expv2/hdr.go Show resolved Hide resolved
output/cloud/expv2/hdr.go Outdated Show resolved Hide resolved
output/cloud/expv2/hdr.go Outdated Show resolved Hide resolved
Base automatically changed from cloud-v2-flushing to master May 30, 2023 08:11
@codebien codebien requested a review from mstoykov May 30, 2023 11:50
output/cloud/expv2/hdr.go Outdated Show resolved Hide resolved
Co-authored-by: Mihail Stoykov <312246+mstoykov@users.noreply.github.com>
output/cloud/expv2/hdr.go Outdated Show resolved Hide resolved
@mstoykov mstoykov requested a review from oleiade May 30, 2023 13:29
mstoykov
mstoykov previously approved these changes May 30, 2023
Copy link
Collaborator

@mstoykov mstoykov left a comment

Choose a reason for hiding this comment

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

LGTM!

I have left a naming nitpick which we can address later or never for that matter 😅

output/cloud/expv2/hdr.go Show resolved Hide resolved
mstoykov
mstoykov previously approved these changes May 30, 2023
@codebien codebien merged commit 7db2dbf into master May 30, 2023
21 checks passed
@codebien codebien deleted the ingestion/histogram branch May 30, 2023 14:24
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.

None yet

5 participants