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

[mknyszek]

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

[rsc]

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.