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

Add the MeterProvider and related packages for review LS-29752 #172

Merged
merged 5 commits into from
Jun 2, 2022

Conversation

jmacd
Copy link
Member

@jmacd jmacd commented May 23, 2022

Description:
The MeterProvider package contains the entry-point to the metrics SDK. This package is accompanied by a number of helper packages, including the basic instrument and number, as well as View configuration structs. Not much happens in this code, it mainly connects the other pieces.

Link to tracking Issue:
LS-29760 describes the overall goal; this is one part.

Testing:
End-to-end testing was done. The alt_metrics_sdk/development branch has a assembled copy of this code. Depends on various Lightstep-side PRs merging to see the exponential histograms work.

Copy link

@paivagustavo paivagustavo left a comment

Choose a reason for hiding this comment

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

Looks really neat. Already got my questions answered via slack, don't think I have too much to add here.

lightstep/sdk/metric/view/view.go Show resolved Hide resolved
Copy link
Member Author

@jmacd jmacd left a comment

Choose a reason for hiding this comment

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

I removed the file periodic.go from this PR because it was completely untested, while everything else is tested in this PR. I will move it to a later review.

lightstep/sdk/metric/view/view.go Show resolved Hide resolved
@jmacd jmacd merged commit fdc9e85 into alt_metrics_sdk/reviewed Jun 2, 2022
@jmacd jmacd deleted the alt_metrics_sdk/provider_review branch June 2, 2022 20:39
lightstep/sdk/metric/asyncinst.go Show resolved Hide resolved
lightstep/sdk/metric/config.go Show resolved Hide resolved
lightstep/sdk/metric/data/data.go Show resolved Hide resolved
lightstep/sdk/metric/number/traits.go Show resolved Hide resolved
lightstep/sdk/metric/number/traits.go Show resolved Hide resolved
lightstep/sdk/metric/producer.go Show resolved Hide resolved
lightstep/sdk/metric/sdkinstrument/kind.go Show resolved Hide resolved
Copy link
Contributor

@njvrzm njvrzm left a comment

Choose a reason for hiding this comment

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

Late to the game, obviously, and my comments are mostly questions or small corrections to the comments. But if you feel like answering any of the questions I will be interested to learn :)

lightstep/sdk/metric/asyncinst.go Show resolved Hide resolved
lightstep/sdk/metric/number/traits.go Show resolved Hide resolved
lightstep/sdk/metric/number/traits.go Show resolved Hide resolved
}
}

// Shutdown stops the stops the export loop, canceling its Context,
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: remove one "stops the"

lightstep/sdk/metric/periodic.go Outdated Show resolved Hide resolved
(*p) = append(*p, empty)
}
return &(*p)[len(*p)-1]
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there cause for concern here that the slices we're reallocating from will have a high-water size behavior?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, that could be a concern. The library takes steps to ensure that the slices are re-used in the same order each time, except for the Points array at the leaf of the structure, which is random-order due to a map iteration. This makes it so that if there's a large allocation here, at least it will be re-used by the same instrument.

If the SDK is cumulative, the allocation will always grow and never shrink. If delta temporality is used, then if a high-cardinality event happens and then stops happening, there will be unused memory here.

lightstep/sdk/metric/provider.go Show resolved Hide resolved
lightstep/sdk/metric/reader.go Show resolved Hide resolved
lightstep/sdk/metric/reader.go Show resolved Hide resolved
lightstep/sdk/metric/view/standard.go Show resolved Hide resolved
Copy link
Member Author

@jmacd jmacd left a comment

Choose a reason for hiding this comment

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

Thanks! I will roll some of these fixes into #173.

lightstep/sdk/metric/asyncinst.go Show resolved Hide resolved
(*p) = append(*p, empty)
}
return &(*p)[len(*p)-1]
}
Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, that could be a concern. The library takes steps to ensure that the slices are re-used in the same order each time, except for the Points array at the leaf of the structure, which is random-order due to a map iteration. This makes it so that if there's a large allocation here, at least it will be re-used by the same instrument.

If the SDK is cumulative, the allocation will always grow and never shrink. If delta temporality is used, then if a high-cardinality event happens and then stops happening, there will be unused memory here.

lightstep/sdk/metric/number/traits.go Show resolved Hide resolved
lightstep/sdk/metric/number/traits.go Show resolved Hide resolved
lightstep/sdk/metric/provider.go Show resolved Hide resolved
lightstep/sdk/metric/reader.go Show resolved Hide resolved
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.

4 participants