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

proposal: expvar: re-export runtime/metrics package statistics #43555

Open
mknyszek opened this issue Jan 6, 2021 · 1 comment
Open

proposal: expvar: re-export runtime/metrics package statistics #43555

mknyszek opened this issue Jan 6, 2021 · 1 comment
Labels
Projects
Milestone

Comments

@mknyszek
Copy link
Contributor

@mknyszek mknyszek commented Jan 6, 2021

Currently the expvar package exports MemStats by default, so should it also include runtime/metrics keys and values? And if so, how?

As a starting point, I'm going to say that it should, and that it should do it the same way MemStats is re-exported: each individual variable isn't discoverable, but the whole MemStats struct is treated as one JSON object.

Some of the problems with doing this is that we would need to pick a name that's unlikely to collide with existing users' exported variable names. Another problem is that runtime/metrics exposes a lot of data through its histograms, making the default results potentially significantly heavier.

An alternative proposal is to export each individual runtime/metrics metric, therefore making them discoverable with expvar's Do and Get. The names are unlikely to collide given that they contain a "/" and a ":", but simultaneously users of the package may not be prepared to deal with these characters, just based on what the package exports by default.

There's also some friction here where expvar seeks to look like and produce JSON, while runtime/metrics doesn't align itself with any particular representation. runtime/metrics.Float64Histogram is the elephant in the room here. Not a huge deal, but we would just need to pick an appropriate representation for it.

Although the title of this proposal takes a position, I'm personally not strongly invested in any particular change. Instead, I want to get feedback from actual users of expvar on what we should do here. It's not clear to me what the best way forward is, including just leaving expvar alone.

CC @bcmills @aclements @prattmic

@gopherbot gopherbot added this to the Proposal milestone Jan 6, 2021
@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Jan 6, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Jan 13, 2021

Expvar is a bit left behind at this point. It may need a rethink generally.
I'd like to hear more about actual uses that want the metrics information before deciding what to do here.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Proposals
Incoming
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants