Hey Prometheus devs,
My name is Michael and I work on the Go runtime at Google.
I wanted to send out a message to the mailing list regarding my intent to add support for reading metrics exported by the
runtime/metrics package in the
Go client. The goal of this new package is to allow the runtime to export implementation-specific metrics. This is useful both for users to gain greater insight into their application's behavior, and for the Go team in understanding performance issues, bugs, and places where we can improve. The core API works a lot like ReadMemStats, but the set of metrics available is significantly more dynamic.
I took a look at the codebase, and AFAICT this switch should be relatively straightforward, and pretty much just amounts to providing a second
goCollector that's used for Go 1.16+. I decided to send a message out to the mailing list because this involves a little bit of refactoring and a medium amount of code, and I didn't want to just show up with a big ol' PR. Does this plan of action sound reasonable to y'all?
I figure a second goCollector should be OK, because the new one will generally be simpler than the existing one. For instance, a lot of the hand-coded data about what each metric means is now available at runtime, like metric descriptions. Metric names can also be programmatically generated, because the runtime/metrics keys are already namespaced. Furthermore, the runtime/metrics package's Read method does not stop-the-world, so all the logic that's working around ReadMemStats' high latency can pretty much disappear in the new goCollector. I figure it will still be worthwhile to re-export some of the metrics under their old names too to avoid breaking dashboards, but I don't know how much of a concern that is here.
Anyway, please let me know what you think!
Thank you,
Michael